[Freebilling-discuss]

[Dmitry]

Hello, Kosta.

As I can see, th only benefit of using EJB in your
model is transparent managing of communications with
client. With another words, we don't have destributed
objects, we have destributed handlers to our
application, the old good 3-tier.

Well, if we are not in position to implement
distributed objects logic because of large ammount of
already written code, then that is probably the best
way. But it seems to me a bit like a microscope used as
a hummer :)

In fact, what I had in mind was (don't be surprised :)

PRESENTATION (CLIENT)
       |
APPLICATION LOGIC (Session and BMP entity beans)       
       |
DATA MODEL
       |
PERSISTENT LAYER

Beans are forming an application. Every entity bean is
linked to some logical entity in the DATA MODEL layer
and used by the client application to represent
it.Every such bean is responsible only for his entity,
so if let╤ say CallTicket bean needs some information
about the customer, it asks the Customer bean, not the
DATA MODEL. Since we can use local interfaces the
performance penalties should be minimal (I'm trying to
test it now).
Why to bother with DATA MODEL then? Because complecs
data processing and calculations will be performed by
session beans, which may require to use several data
model entities to accomplish the job.

-------------------------------------------------------------------------------
APPLICATION:
       --------------------------             
----------------------
       | CallTicket entity bean | <----------->| Client
entity bean |
       --------------------------             
----------------------
             |           ^                        ^   
         |
             |           |                        |   
         |
             |           v                        v             |
             |        ---------------------------------
        |
             |        | CallTicketsTools session bean |
        |
             |        ---------------------------------
        |
             |           |                        |   
         |
-------------|-----------|------------------------|-------------|--------------
             |           |                        |   
         |
             v           v                        v   
         v           
-------------------------------------------------------------------------------
DATA MODEL:  CallTicket data entity              Client
data entity
-------------------------------------------------------------------------------

As I understand, IF we consider that model, we will
meet a problem of "legacy" :) java code and pressing
deadline. That is why my proposition for that pressing
time been is to have your model (application logic as
plain java on top of DATA MODEL layer), but design
adapters keeping in mind the posibility of later move
to the EJB application model (in fact both of these
models can even work in together). What does it mean
practically? That means that we shell use entity bean
adapters for logical data entities (as we would use it
in EJB application). Later we can move code from
application layer to the corresponding session and
entity beans (one by one), test them and deploy instead
of application layer. 

What do you think?
Dima.