Marcus wrote:
"Stock standard = just the regular, right?"
Correct and sorry for the non-international terminology.
Marcus wrote:
"What do you get by having the state objects implementing
the same interface as the remote interface does inherit,
apart of the changability between them and remote interfaces?
To me this seems like creating a proxy instead of the adapter
which would allow for greater flexibility."
That changability was the point -- for us at least. The flexibility we were
going for was the ability to change our minds about passing state objects or
remote interfaces. There are several services that we have run both inside and
outside of the EJB Server's (WebLogic's) JVM. This affects our choice of
whether to pass states or remotes. We keep changing our minds based upon a
number of external issues that I won't go into here. However it has been very
convenient not to have to re-code any of these clients when we toggle the
state/remote option.
An advantage of our business-interface/state/remote pattern is that the analysis
models can focus on business classes and their relationships -- and are remain
EJB-free. A second payback is that the compiler can now enforce that my bean,
remote, and state objects all are in sync. (The bean class also implements the
business interface)
Regarding your comment on the previous post:
"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."
We have in mind to try this in a later iteration. Right now, we're muscling it
through our session bean service layer -- for no other reason other than
expedience. (We're trying to strike that balance between the perfect
implementation and actually delivering a functional system)
NOTE: We have employed adapters around the business interfaces for
one of our client services -- due mainly to that service's constraints
on attribute naming and datatypes.
-Tom
-----Original Message-----
From: Marcus Ahnve <[EMAIL PROTECTED]>
Sent: Monday, April 10, 2000 8:44 PM
To: [EMAIL PROTECTED]
Subject: Re: 'local' entity beans vs dependent objects
> 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 = just the regular, right? I reread your post and I think
I understood it this time. If so I believe that the last part of my last
post did not address your question, sorry about that.
What do you get by having the state objects implementing the same
interface as the remote interface does inherit, apart of the
changability between them and remote interfaces? To me this seems like
creating a proxy instead of the adapter which would allow for greater
flexibility.
As far as life cycle goes I have this idea about having the a bean
returning a object by value for modification on the client and then
updating it to the persistent storage, as I mentioned in my last post.
This was what we did in a non EJB environment (NetDynamics 4) when I was
involved in a large travel booking service where the business rules were
ridiculously complex. However after following what the people from
Gemstone and Versant has had to say about this topic I'm not certain
that I want the entity beans at all, I'm right now more into having it
their suggested way with a session bean accessing a object database.
And I really think you can do the most awesome things if you put Jini
into the mix, for the appropriate systems of course.
These are just vague thoughts though, I hope to be able to try them out
later.
Regards,
/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".
===========================================================================
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".
