Delicate issue here ... I think you are merging the roles of developer, app
assembler, and deployer a bit here, where the EJB spec tries to keep them
separate.
As a third party bean provider I assume you intend to sell each of your
components separately (else why not just package them together?). So, I
would think all you should sensibly specify is *logical* connection between
the components you supply; if you start specifying deployment you will
restrict the individual selling-value of each component. It seems to me that
each application will have different levels of intensity of connection
between your components, depending on the underlying data and which parts of
the object's behavior you're invoking.
And since the application assembler follows the bean provider in the food
chain, how can you the third-party bean provider know what beans you are
associated with, to know which beans you need session affinity with?
This comes down to what *relationships* logically exist between the beans,
in the context of the application. Now, I certainly agree the EJB 1.1 spec
is gloriously lacking in association management between beans; no way to
specify the relationship ("this RoomBean has a 1:n relationship with a set
of ReservationBeans") and have the container manage the beans activation
strategies, nor perform complex O/R mapping to get the right keys into the
underlying tables.
Assume we get that capability, though, in EJB 2.0 - now, would you really
want to insert deployment hints in with all that relationship stuff, or
would you want the server to consider the relationship info and deploy
accordingly.
Wayne
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Sean Johnson
Sent: Friday, June 02, 2000 8:25 AM
To: Wayne Stidolph
Cc: [EMAIL PROTECTED]
Subject: RE: Questions about the EJB paradigm
[snipped lots of great stuff about Enhydra/JOnAS's future]
Hi Wayne. Great input on this issue by the way.
> As to these problems being not addressed by the EJB spec, I think that is
> intentional: the spec is philosophically keen on the idea of location
> transparency for each bean, and on the idea of different vendors
> implmenting
> different quality of service for different scales. In the very-nice Open
> Source case, you get to affect that QoS decision, or even override the
> implementation we provide.
This is where I think two of the specs philosophies are colliding a bit. It
is true that the spec is keen on maintaining location transparency, which
is definitely a good thing. But the spec./Sun/Vendor community is also keen
on there being a third party market for EJBs. If I am a IS developer and
I can target one application server then the current spec. is great. I can
pick the application server that provides the level and type of scaling that
my application needs and it is all good. But if I am an ISV trying to
provide
third party beans to the market how do I make intelligent design decisions
given
the open ended ness of the current spec. in regards to scaling schemes? I
think
the spec. needs to encroach a bit on the location issue, not in code, you
still
would like location transparency there, but in the standard EJB deployment
descriptors. So as a vendor I can enforce some simple scaling decisions
for my beans and be assured that my customers can deploy on any EJB X.X
compliant
application server and get the benefits of my decision as well as the
additional
scaling and management features offered by the application sever they chose.
An example may be in order here. Borrowed from your example is the question
of session affinity. The application server can't know if two beans are
going
to have a coarse grained or fine-grained conversation. So how does it decide
if session affinity is good for this lookup (fine-grained) or bad for this
lookup (coarse-grained, so I want the least loaded server)? It decides
because
I tell it in my deployment descriptors whether I prefer session affinity or
not.
> we'll ensure the servent-selector is easy to replace on a
> per-Context basis, so you can essentially "tune" this somewhat to you
application,
> even having different selection functions for different resources
according to the way
> you lay out the namespace.)
See this doesn't help third party bean vendors unless it's part of the spec.
because they can't
take advantage of it. There needs to be flexibility in the spec. for the
third party
vendor to somewhat "tune" their application since they are the ones who
truly
understand the application and are held liable by the client when the poorly
"tuned" application performs miserably. Including instructions for how to
tune every
app. server in the market for the needs of your application is not a viable
alternative.
There needs to be a way to codify these decisions in the bean that is sold
the
the customer.
Later,
Sean
----
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body of the message "unsubscribe jonas-users".
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 "unsubscribe jonas-users".
For general help, send email to [EMAIL PROTECTED] and
include in the body of the message "help".
