Is it legal to have an ejbbean making calls to static methods of other
classes ?
I know it is possible because it is working in our code. What I fear
are the effect on the container managed transactions, security etc.
If this is possible we could write a single session bean that calls
many different static business methods from 200+ classes. Otherwise
we should make 200+ sesion beans which looks ugly to me.
Best regards
Javier Borrajo
www.tid.es
>> Same thing has been bothering me as I am about
>> to embark on fairly large EJB based project.
>>
>> IMO this is one of the major questions which
>> needs to be addressed by the EJB dev community.
>> There are many OO systems that have domain object
>> models as a conerstone of their design. Most of
>> these models involve complex inheritence and
>> association relationships. Polymorphic behaviour
>> is important in this modeling.
>>
>> I have been following this discussion group and
>> I am yet to come across a suggestion of a
>> reasonable pattern for implementing DOM's in an
>> EJB based environment. Most threads where this
>> is discussed end up in a debate around the evils
>> of inheritence as opposed to delegation.
>>
>> This to me is missing the point. The issue is:
>> we have inheritence in OO analysis, design, and
>> implementation. It is a powerful tool when used
>> correctly. The Java environment itself relies
>> heavily on it and encourages it use in the
>> programming model, and yet to my knowledge there
>> is no clear and simple way for using it with EJB's.
>>
>> DOM's usually reflect:
>> - "entity" (Jacobson) type objects involved in the
>> problem domain.
>> - These entity objects have state.
>> - The state needs to persist beyond the lifecycle
>> of one process
>> - There are generalizations and specializations of
>> entities.
>> - They are involved in units of work (transactions)
>
>> Entity EJB's seem to be the perfect answer at an
>> implementation level for dealing with these
>> requirements.
>
>I believe the consensus on this list would disagree with you. Entity beans
>are not the runtime construct to use for every DOM object because the EJB
>model is a distributed component model not an object model. Among several
>significant problems, inter-EB method calls are far too inefficient to be
>used for method in vocations on fine-grained objects.
>
>> Echoing Michael's question: What then are
>> strategies/patterns for implementing domain
>> objects to entity EJbeans?
>
>Here's a proposed "strategy" in outline:
>
>1. take your DOM
>
>2. overlay it with "components", Components are coarse-grained,
>independently deployable, distributable locales for application code and
>will correspont to EJBs when we come to write the actual code. Plan for
>where the components are to execute (client or server). Components can
>overlap (so that function is deployed multiple places). Component will not
>always enclose complete DOM objects. (so that some logic for an object can
>be placed on the client, and other logic for the same object on the
>server). Make sure that you are happy with where function is executed from
>a security perspective. I would expect DOM relationships such as
>inheritance to remain within a component - in other words no inheritance
>between components.
>
>3. look at use cases to define transaction boundaries. Preferably these
>should coincide with component boundaries to avoid explicit transaction
>management appearing in the code.
>
>4. look at use cases and where necessary reduce the frequency of flows
>between components by creating tailored message objects ("buckets").
>
>5. look at how to persist the instance data of a component. There is a
>trade-off between instantiating all state data initially which could slow
>dowm some usecases, and constantly faulting to fetch data that has not yet
>been instantiated which could slow down other use cases.
>
>6. Use what you did in steps 2-5 to create a separate DOM for each
>component that includes the "technical" objects such as buckets. Perhaps we
>should call this the "Technical Object Model", TOM.
>
>6. Write/generate the code to the EJB runtime environment for each
>component from its DOM.
>
>Hope this helps...
>
>Ian McCallion
>CICS Business Unit
>IBM Hursley
>[EMAIL PROTECTED]
>Tel: ++44-1962-818065
>Fax: ++44-1962-818069
>
>===========================================================================
>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".
