Noel, we definitely understand we don't have an exclusive "lock" on
any ASF land; we understand perfectly that's not how the ASF works :)
-David
On May 1, 2007, at 12:47 AM, Noel J. Bergman wrote:
David Blevins wrote:
Noel J. Bergman wrote:
David Blevins wrote:
We could use "Scalable, transactional, and multi-user
secure architecture for the development and deployment
of component-based business applications"
How would that differ from River or WS (various WS-* specs cover
transactions and security)?
They don't differ really as EJBs are web services too.
Perhaps this is devolving into a bikeshed, but I am thinking that the
description ought to either distinguish OpenEJB from any of several
other
such projects at the ASF, or not sound like it has an exclusive on the
territory. At this point, I've lost track of what text you're
proposing in
context (context of these text segments being the key point), so
just give
this some thought.
The definition of ejb spells out "Scalable, transactional, and
multi-user secure" which is summed up by the word 'enterprise'.
So maybe something like "creation and maintenance of enterprise
application containers and object distribution". Maybe expand
that last part to "object distribution servers", kind of awkward
but uses Container and Server which are the primary two words
we use to describe our architecture
Those are words used throughout the JEE model: Web Container, EJB
container, Portlet Container (superclass of Servlet Container),
Client Container, Applet Container, ... JEE is all about container
managed components.
None of those you listed are transactional except EJB.
I was referring to the words "container and server" being your
"primary two
words", hence my enumeration of the various containers (yes, not
all are on
the server-side). The transaction managing container is probably
closer to
one of your distinguishing characteristics.
the security in Web Containers (superclass of Portlet, not the other
way around) is very focused on transports and has no other mechanisms
for securing application logic.
I'd view that as wrong on all counts, but let's not further hijack the
thread. Catch me elsewhere if you want to discuss it.
We've always supported plugging in containers that support other
models, so the answer is anything capable of being invoked. With
the latest EJB spec, that's pretty much a requirement as any Plain
Old Java Object can be deployed into an EJB container. You no longer
have to make the distinction in your application code.
So there is really nothing to distinguish between OpenEJB and
Geronimo, for
example, in so far as the description of the scope of the project.
Again,
not necessarily an issue, except for any implication in the
phrasing that
the project has an exclusive on the listed concepts.
if we wanted to just say "The ASF definition of OpenEJB is EJB"
and let it be that, I personally wouldn't be inconvenienced as
I am one of the few people who get to decide what EJB means. Even
though Apache gets a seat on expert groups, they are still closed
groups.
A separate matter that needs to be addressed by the entire Java
community
with the JCP. JSRs really need to become more open uniformly, not
just the
few run by more enlightened spec leads.
there is a problem space that EJB aims to solve and much of what
OpenEJB offers in that problem space will never be part of the
EJB spec or is part of another spec (like, EARs and Client
Containers), so simply calling it "EJB" doesn't seem like it covers
the whole project.
Fair enough. There is a lot that's under the JEE umbrella, not
under the
piece labeled EJB. And a supporting argument that there are many (and
sometimes necessary) extensions to EJB in vendor EJB products such as
WebSphere. Again, I would ontologically expect to find some in
Geronimo
more than in OpenEJB, but we don't parcel out functional areas for ASF
projects. Just make sure that it doesn't sound like you've claimed
one.
This discussion has already resulted in a much better description
of the EJB problem space, IMHO.
:-)
By the way, anyone here at ApacheCon?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
