You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Brett Porter <br...@gmail.com> on 2007/04/24 05:51:16 UTC

[vote] Propose OpenEJB for graduation to a TLP

Hi to all incubator PMC folk,

The OpenEJB community have voted to ask the incubator PMC to
recommended the following resolution to the board.

For further reference, see the earlier thread on this list:
http://www.nabble.com/-proposal--OpenEJB-Graduation-Proposal-tf3509732.html#a9803491
Note that the community has come to consensus on the list of initial
PMC members unanimously.

Please cast your votes on whether to recommend this proposal.

Thanks,
Brett
(OpenEJB Mentor)

       Establish Apache OpenEJB Project

       WHEREAS, the Board of Directors deems it to be in the best
       interests of the Foundation and consistent with the Foundation's
       purpose to establish a Project Management Committee charged with
       the creation and maintenance of open-source software related to
       enterprise application and remoting services, for distribution at
       no charge to the public.

       NOW, THEREFORE, BE IT RESOLVED, that a Project Management
       Committee (PMC), to be known as the "The Apache OpenEJB Project",
       be and hereby is established pursuant to Bylaws of the
       Foundation; and be it further

       RESOLVED, that The Apache OpenEJB Project be and hereby is
       responsible for the creation and maintenance of a software
       project related to enterprise application and remoting services;
       and be it further

       RESOLVED, that the office of "Vice President, OpenEJB" be and
       hereby is created, the person holding such office to serve at the
       direction of the Board of Directors as the chair of The Apache
       OpenEJB Project, and to have primary responsibility for
       management of the projects within the scope of responsibility of
       The Apache OpenEJB Project; and be it further

       RESOLVED, that the persons listed immediately below be and
       hereby are appointed to serve as the initial members of The
       Apache OpenEJB Project:

         * David Blevins       (dblevins@apache.org)
         * Alan Cabrera        (adc@apache.org)
         * David Jencks        (djencks@apache.org)
         * Jacek Laskowski     (jlaskowski@apache.org)
         * Brett Porter        (brett@apache.org)
         * Dain Sundstrom      (dain@apache.org)

       NOW, THEREFORE, BE IT FURTHER RESOLVED, that David Blevins be and
       hereby is appointed to the office of Vice President, OpenEJB, to
       serve in accordance with and subject to the direction of the Board
       of Directors and the Bylaws of the Foundation until death,
       resignation, retirement, removal or disqualification, or until a
       successor is appointed; and be it further

       RESOLVED, that the initial Apache OpenEJB Project be and hereby
       is tasked with the migration and rationalization of the Apache
       Incubator OpenEJB podling; and be it further

       RESOLVED, that all responsibility pertaining to the Apache
       Incubator OpenEJB podling encumbered upon the Apache Incubator
       PMC are hereafter discharged.

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by Brett Porter <br...@gmail.com>.
On 30/04/07, Noel J. Bergman <no...@devtech.com> wrote:
> Is that still true of companies owned by the same entity are counted as one
> (e.g., IBM, Lotus and Tivoli would count as a single employer)?

Yup.

- Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On Apr 30, 2007, at 4:57 PM, Sanjiva Weerawarana wrote:

> David Blevins wrote:
>>> Couldn't that be "in EJB and related technologies" ??
>> Certainly implementing the EJB spec is a constant for the project,  
>> so that description would be adequate.  It does give me an "ick"  
>> feeling though as it's very much in the nature of the project to  
>> go beyond EJB and test the limits of what it means to write  
>> enterprise applications in any way we can possibly imagine.  It  
>> just seems summing that up as "and related technologies" just  
>> doesn't capture that spirit.  It'd definitely be our preference to  
>> be able to portray ourselves as more than just EJB.
>
> +1 for keeping that room, but in that case maybe come up with a  
> better name than OpenEJB? The name is clearly designed to imply  
> certain functionality.

I don't think calling it OpenEJB is such a big issue.  The project is  
seven years old so a lot of us are really tied to the name and I  
think it does allow is the advantage to stretch the world of EJB a  
bit and still have people understand more or less what we're about.   
We hope though as they learn more about us they appreciate/love that  
we do things other EJB implementations don't/won't do and we aren't  
afraid to go outside the spec to do it.  We hope that it results in  
people thinking "hey, cool, that's how all ejb containers should  
work" or "this should be part of the spec."

-David



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
David Blevins wrote:
>> Couldn't that be "in EJB and related technologies" ??
> 
> Certainly implementing the EJB spec is a constant for the project, so 
> that description would be adequate.  It does give me an "ick" feeling 
> though as it's very much in the nature of the project to go beyond EJB 
> and test the limits of what it means to write enterprise applications in 
> any way we can possibly imagine.  It just seems summing that up as "and 
> related technologies" just doesn't capture that spirit.  It'd definitely 
> be our preference to be able to portray ourselves as more than just EJB.

+1 for keeping that room, but in that case maybe come up with a better 
name than OpenEJB? The name is clearly designed to imply certain 
functionality.

Sanjiva.
-- 
Sanjiva Weerawarana, Ph.D.
Founder & Director; Lanka Software Foundation; http://www.opensource.lk/
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
Director; Open Source Initiative; http://www.opensource.org/
Member; Apache Software Foundation; http://www.apache.org/
Visiting Lecturer; University of Moratuwa; http://www.cse.mrt.ac.lk/

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On Apr 24, 2007, at 7:41 PM, Niclas Hedhman wrote:

> On Wednesday 25 April 2007 08:31, David Blevins wrote:
>
>> Generally, I think it's good to use words that describe EJB then the
>> words Enterprise JavaBeans specifically.  Primarily because I think
>> it's good to be able to innovate in the space and not limit ourselves
>> to the ideas approved by the EJB JSR Expert Group.
>
> Couldn't that be "in EJB and related technologies" ??

Certainly implementing the EJB spec is a constant for the project, so  
that description would be adequate.  It does give me an "ick" feeling  
though as it's very much in the nature of the project to go beyond  
EJB and test the limits of what it means to write enterprise  
applications in any way we can possibly imagine.  It just seems  
summing that up as "and related technologies" just doesn't capture  
that spirit.  It'd definitely be our preference to be able to portray  
ourselves as more than just EJB.


-David






---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 25 April 2007 08:31, David Blevins wrote:

> Generally, I think it's good to use words that describe EJB then the
> words Enterprise JavaBeans specifically.  Primarily because I think
> it's good to be able to innovate in the space and not limit ourselves
> to the ideas approved by the EJB JSR Expert Group.

Couldn't that be "in EJB and related technologies" ??


Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On May 2, 2007, at 3:23 AM, Noel J. Bergman wrote:

> David Blevins wrote:
>
>> Here's the revised language:
>
>        RESOLVED, that The Apache OpenEJB Project be and hereby is
>        responsible for the creation and maintenance of a software
>        project related to enterprise application containers and
>        object distribution services [based on, but not limited to
>        the Enterprice Java Beans Specification]; and be it further
>
> Does that work for you?  It feels more descriptive without being  
> limiting.

Works for me.

-David


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
David Blevins wrote:

> Here's the revised language:

       RESOLVED, that The Apache OpenEJB Project be and hereby is
       responsible for the creation and maintenance of a software
       project related to enterprise application containers and
       object distribution services [based on, but not limited to
       the Enterprice Java Beans Specification]; and be it further

Does that work for you?  It feels more descriptive without being limiting.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On May 1, 2007, at 1:27 PM, Noel J. Bergman wrote:

>> we definitely understand we don't have an exclusive "lock" on
>> any ASF land; we understand perfectly that's not how the ASF works :)
>
> :-)
>
> As I allowed earlier, the discourse devolved a bit into a  
> bikeshed.  :-)  I
> look forward to the revised language, and OpenEJB's graduation.

:)

Here's the revised language:

  http://svn.apache.org/repos/asf/incubator/openejb/trunk/graduation- 
resolution.txt

Contains some good verbiage from Robert "enterprise application  
containers" and a more specific description of the nature of our  
server half, "distributed object services".

I think it fits us like a glove (way better than what we had) and  
we've already gotten some good feedback on it at the openejb dev  
list, but if you see some room for improvement we're happy to  
incorporate it.

Thanks!

-David


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
> we definitely understand we don't have an exclusive "lock" on
> any ASF land; we understand perfectly that's not how the ASF works :)

:-)

As I allowed earlier, the discourse devolved a bit into a bikeshed.  :-)  I
look forward to the revised language, and OpenEJB's graduation.

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
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: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
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.

Noel J. Bergman wrote:
> David Blevins wrote:
>>> 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.

Somewhat true.  None of those you listed are transactional except  
EJB.  Applets (not actually part of JEE) and Client Containers are  
not multi-user secure or scalable.  And 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.

Noel J. Bergman wrote:
> David Blevins wrote:
>> Ok, going with "object distribution services" as I think that
>> describes a less singular approach to supporting distributed
>> objects.  At current date we support invocations over our custom
>> protocol, CORBA, HTTP, JMS, JAX-RPC, JAX-WS, even telnet.  We
>> have a container/server contract and a server implementation
>> that allows for numberous ServerService (i.e. protocols) to be
>> plugged in and standardly configured in an xinet.d style config.
>
> Invocations of what?  What types of components are supported by the
> container?  The EJB contract, surely.  Other components too, just  
> different
> means to invoke EJB components?

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.

Noel J. Bergman wrote:
> David Blevins wrote:
>> Generally, I think it's good to use words that describe EJB then the
>> words Enterprise JavaBeans specifically.  Primarily because I think
>> it's good to be able to innovate in the space and not limit ourselves
>> to the ideas approved by the EJB JSR Expert Group.
>
> Isn't the point of OpenEJB to implement the EJB Spec?  I understand  
> that
> "it's very much in the nature of the project to go beyond EJB and  
> test the
> limits of what it means to write enterprise applications in any way  
> we can
> possibly imagine", but that feels a bit fuzzy.  Perhaps it doesn't  
> matter,
> but ... <<shrug>>

I know it seems like half a dozen of one and six of the other, but  
there is an important difference community wise.  The OpenEJB  
community does not get to decide what goes into the EJB spec.  I  
personally have had the privilege to participate in the EJB expert  
group.  So 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.  Also, 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.

Does any of that make any sense?  I do wonder if I'm far too close to  
the subject, so outside feedback is definitely helpful.  This  
discussion has already resulted in a much better description of the  
EJB problem space, IMHO.

-David




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
David Blevins wrote:
>> 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.

> Ok, going with "object distribution services" as I think that
> describes a less singular approach to supporting distributed
> objects.  At current date we support invocations over our custom
> protocol, CORBA, HTTP, JMS, JAX-RPC, JAX-WS, even telnet.  We
> have a container/server contract and a server implementation
> that allows for numberous ServerService (i.e. protocols) to be
> plugged in and standardly configured in an xinet.d style config.

Invocations of what?  What types of components are supported by the
container?  The EJB contract, surely.  Other components too, just different
means to invoke EJB components?

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On Apr 27, 2007, at 3:19 PM, David Blevins wrote:

>
> On Apr 27, 2007, at 12:40 PM, robert burrell donkin wrote:
>
>> On 4/25/07, David Blevins <da...@visi.com> wrote:
>>>
>>> On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:
>>>
>>> > On 24/04/07, Noel J. Bergman <no...@devtech.com> wrote:
>>> >>
>>> >> > the creation and maintenance of open-source software related to
>>> >> > enterprise application and remoting services, for  
>>> distribution at
>>> >> > no charge to the public.
>>> >>
>>> >> A bit generic for a project that is intended to managing an
>>> >> implementation
>>> >> of a well-defined specification?
>>> >>
>>> >
>>> > I think it's accurate - it doesn't implement the entire EJB spec
>>> > (using other components such as OpenJPA to do so), and it would  
>>> be in
>>> > scope to do additional, non-EJB things that make it better at the
>>> > purpose stated here.
>>>
>>> We could use "Scalable, transactional, and multi-user secure
>>> architecture for the development and deployment of component-based
>>> business applications", but that'd be plagiarism as that's a
>>> minimally paraphrased version the definition of EJB in the JSR.
>>>
>>> Generally, I think it's good to use words that describe EJB then the
>>> words Enterprise JavaBeans specifically.  Primarily because I think
>>> it's good to be able to innovate in the space and not limit  
>>> ourselves
>>> to the ideas approved by the EJB JSR Expert Group.
>>
>> i see your point but the original language isn't great: it's all a
>> little wholly. for example, "remoting services" could be read as
>> service provision.
>>
>> perhaps something more like: "creation and maintenance of
>> transactional application containers capable of connection by remote
>> clients"...?
>
> That could work.  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 (i.e. the  
> openejb container/server contract).  Or one last mutation could be  
> to use "services" instead of "server" which might be less awkward,  
> giving us "object distribution services".
>
> Preferences, thoughts?

Ok, going with "object distribution services" as I think that  
describes a less singular approach to supporting distributed  
objects.  At current date we support invocations over our custom  
protocol, CORBA, HTTP, JMS, JAX-RPC, JAX-WS, even telnet.  We have a  
container/server contract and a server implementation that allows for  
numberous ServerService (i.e. protocols) to be plugged in and  
standardly configured in an xinet.d style config.  Adding a new  
protocol is literally an act of dropping in a jar and rebooting.  And  
I'm not sure what is meant by "service provisioning", but we do have  
the capability for you to deploy a client app in advance and then  
walk up to the server later with an empty client and sort of say "I  
want to be client 'foo'" and your empty client will download all the  
previously deployed environment for client "foo" (i.e. security info,  
naming entries, ejb references, jms queue/topic references, etc.).

-David






---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On Apr 27, 2007, at 12:40 PM, robert burrell donkin wrote:

> On 4/25/07, David Blevins <da...@visi.com> wrote:
>>
>> On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:
>>
>> > On 24/04/07, Noel J. Bergman <no...@devtech.com> wrote:
>> >>
>> >> > the creation and maintenance of open-source software related to
>> >> > enterprise application and remoting services, for  
>> distribution at
>> >> > no charge to the public.
>> >>
>> >> A bit generic for a project that is intended to managing an
>> >> implementation
>> >> of a well-defined specification?
>> >>
>> >
>> > I think it's accurate - it doesn't implement the entire EJB spec
>> > (using other components such as OpenJPA to do so), and it would  
>> be in
>> > scope to do additional, non-EJB things that make it better at the
>> > purpose stated here.
>>
>> We could use "Scalable, transactional, and multi-user secure
>> architecture for the development and deployment of component-based
>> business applications", but that'd be plagiarism as that's a
>> minimally paraphrased version the definition of EJB in the JSR.
>>
>> Generally, I think it's good to use words that describe EJB then the
>> words Enterprise JavaBeans specifically.  Primarily because I think
>> it's good to be able to innovate in the space and not limit ourselves
>> to the ideas approved by the EJB JSR Expert Group.
>
> i see your point but the original language isn't great: it's all a
> little wholly. for example, "remoting services" could be read as
> service provision.
>
> perhaps something more like: "creation and maintenance of
> transactional application containers capable of connection by remote
> clients"...?

That could work.  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 (i.e. the openejb container/ 
server contract).  Or one last mutation could be to use "services"  
instead of "server" which might be less awkward, giving us "object  
distribution services".

Preferences, thoughts?

-David


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by robert burrell donkin <ro...@gmail.com>.
On 4/25/07, David Blevins <da...@visi.com> wrote:
>
> On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:
>
> > On 24/04/07, Noel J. Bergman <no...@devtech.com> wrote:
> >>
> >> > the creation and maintenance of open-source software related to
> >> > enterprise application and remoting services, for distribution at
> >> > no charge to the public.
> >>
> >> A bit generic for a project that is intended to managing an
> >> implementation
> >> of a well-defined specification?
> >>
> >
> > I think it's accurate - it doesn't implement the entire EJB spec
> > (using other components such as OpenJPA to do so), and it would be in
> > scope to do additional, non-EJB things that make it better at the
> > purpose stated here.
>
> We could use "Scalable, transactional, and multi-user secure
> architecture for the development and deployment of component-based
> business applications", but that'd be plagiarism as that's a
> minimally paraphrased version the definition of EJB in the JSR.
>
> Generally, I think it's good to use words that describe EJB then the
> words Enterprise JavaBeans specifically.  Primarily because I think
> it's good to be able to innovate in the space and not limit ourselves
> to the ideas approved by the EJB JSR Expert Group.

i see your point but the original language isn't great: it's all a
little wholly. for example, "remoting services" could be read as
service provision.

perhaps something more like: "creation and maintenance of
transactional application containers capable of connection by remote
clients"...?

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
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)?

> Generally, I think it's good to use words that describe EJB then the
> words Enterprise JavaBeans specifically.  Primarily because I think
> it's good to be able to innovate in the space and not limit ourselves
> to the ideas approved by the EJB JSR Expert Group.

Isn't the point of OpenEJB to implement the EJB Spec?  I understand that
"it's very much in the nature of the project to go beyond EJB and test the
limits of what it means to write enterprise applications in any way we can
possibly imagine", but that feels a bit fuzzy.  Perhaps it doesn't matter,
but ... <<shrug>>

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:

> On 24/04/07, Noel J. Bergman <no...@devtech.com> wrote:
>>
>> > the creation and maintenance of open-source software related to
>> > enterprise application and remoting services, for distribution at
>> > no charge to the public.
>>
>> A bit generic for a project that is intended to managing an  
>> implementation
>> of a well-defined specification?
>>
>
> I think it's accurate - it doesn't implement the entire EJB spec
> (using other components such as OpenJPA to do so), and it would be in
> scope to do additional, non-EJB things that make it better at the
> purpose stated here.

We could use "Scalable, transactional, and multi-user secure  
architecture for the development and deployment of component-based  
business applications", but that'd be plagiarism as that's a  
minimally paraphrased version the definition of EJB in the JSR.

Generally, I think it's good to use words that describe EJB then the  
words Enterprise JavaBeans specifically.  Primarily because I think  
it's good to be able to innovate in the space and not limit ourselves  
to the ideas approved by the EJB JSR Expert Group.

-David




---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett Porter wrote:
> Noel J. Bergman asked:
> > What is the diversity of the Committer list and the PMC?
> There are individuals from >= 3 employers in both committers and the PMC.

Is that still true of companies owned by the same entity are counted as one
(e.g., IBM, Lotus and Tivoli would count as a single employer)?

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by Brett Porter <br...@gmail.com>.
On 24/04/07, Noel J. Bergman <no...@devtech.com> wrote:
> Brett,
>
> What is the diversity of the Committer list and the PMC?

There are individuals from >= 3 employers in both committers and the PMC.

>
> > the creation and maintenance of open-source software related to
> > enterprise application and remoting services, for distribution at
> > no charge to the public.
>
> A bit generic for a project that is intended to managing an implementation
> of a well-defined specification?
>

I think it's accurate - it doesn't implement the entire EJB spec
(using other components such as OpenJPA to do so), and it would be in
scope to do additional, non-EJB things that make it better at the
purpose stated here.

Thanks,
Brett

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 27 April 2007 13:12, David Blevins wrote:
> Haven't seen any more discussion, so just following up.  Noel, were
> your questions answered to your liking?  Niclas?

+1 to graduate OpenEJB to TLP.

Cheers
-- 
Niclas Hedhman, Software Developer

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Re: [vote] Propose OpenEJB for graduation to a TLP

Posted by David Blevins <da...@visi.com>.
Haven't seen any more discussion, so just following up.  Noel, were  
your questions answered to your liking?  Niclas?

-David

On Apr 24, 2007, at 10:09 AM, Noel J. Bergman wrote:

> Brett,
>
> What is the diversity of the Committer list and the PMC?
>
>> the creation and maintenance of open-source software related to
>> enterprise application and remoting services, for distribution at
>> no charge to the public.
>
> A bit generic for a project that is intended to managing an  
> implementation
> of a well-defined specification?
>
> 	--- Noel
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


RE: [vote] Propose OpenEJB for graduation to a TLP

Posted by "Noel J. Bergman" <no...@devtech.com>.
Brett,

What is the diversity of the Committer list and the PMC?

> the creation and maintenance of open-source software related to
> enterprise application and remoting services, for distribution at
> no charge to the public.

A bit generic for a project that is intended to managing an implementation
of a well-defined specification?

	--- Noel



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org