incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: [vote] Propose OpenEJB for graduation to a TLP
Date Tue, 01 May 2007 19:52:11 GMT
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 :)


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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message