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]
