[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".
