Tom Larson wrote:
>
> I've been reading this thread for days with great interest.
>
> I have some questions for Marcus or Laird about the current approach.
>
> The Setup
> ---------
> The solution you propose involves wrapping entity beans with an EJB independent
> interface. However, a significant part of the EJB interface involves entity
> bean life cycle stuff -- i.e. creation, query, mutation, and destruction of
> persistent objects. These functions aren't specific to EJB persistent objects.
> If we wrap the beans then we have to develop our own API for these functions.
> It seems that we'll each end up with our own EJB-like, home-grown, persistent
> object management layer.
The really sorry part is that I haven't had the time to try it out for
real, for me it's mostly in theory so far. But generally, I always try
to keep proprietary stuff out my design. I used to do a lot of work with
NetDynamics 4, and fought those spider.* with a flamethrower every day
;-). I do not necessarily believe in code reuse, but definitely in
design reuse. If I have to tweak my design into what is hot on the
market today, I will have to redo it tomorrow when the brand new and
much faster one pops up. If the component model fits your business
model, rock on, but the main thing for me is to keep a clear interface.
So I guess you would have to develop your own API for all those
functions you're mentioning, but you would probably be able to keep it
on a higher level than straightforward EJB. If you can develop an
interface that satisfies your system need regardless of component model,
I'd say you are two steps ahead the next time something new comes along.
> The Questions
> -------------
> Is this what we want?
I for one do not want my own, probably not as good, EJB copy. But I have
previously been developing what you may call a home-grown, persistent
object management layer. During that work we came up with a couple of
nice designs for remote state that I would like to be able to reuse and
so far I've had problems squeezing it into the entity bean model. I do
believe that different systems need different ways of dealing with
state, persistance etc. IMHO the focus of most EJB related stuff is the
fairly straight forward case of net shopping with the shopping cart,
session bean, and the persistent stuff, orders etc, in the relational
db, entity beans. If however you want to use the same component model
because of its transactional, load balancing etcetera capabilities to
solve another problem you may find it not so well suited to it. These
are the cases I try to address.
> Is this worth the cost given your assessment of the
> likelihood of swapping component models?
I believe that's up to for decision on every project and every separate
system, I don't believe in silver bullets. I believe you may find it
worth the cost. But there are people who claim I've been wrong before
;-)
> Miscellany
> ----------
> We are using what we call "state objects" to pass entity bean state to clients
> to avoid what would otherwise be an incredible amount of getter traffic on the
> net. We also have developed "business interfaces" that both the state objects
> and remote interfaces implement. This allows us the flexibility to change our
> minds about whether a client should deal with remote interfaces or state
> objects. However, when it comes to life cycle stuff, we're using the stock
> standard entity bean interfaces provided by EJB.
Stock standard? I guess my swedish heritage caught up with me because
I'm not sure I understand what you mean. But the state objects you're
mentioning sounds really interesting. I've been thinking about something
along the same lines for applications with a high need of local state. A
cool thing would be if you could get a local copy of your object and
work on it, and check it back in when done with automatic updates to the
persitent storage, whatever it may be. Think what Jini could do for you,
with different objects knowing about each other on the network. Not
suitable for large scale systems, I know, I know, but certainly usable
in some cases.
Whoops, drifting off-topic, got to go back to work I guess.
Just my two swedish kronor.
/Marcus
Marcus Ahnve
Sun Java Center
Sweden
===========================================================================
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".
