Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of david.blevins@visi.com
 designates 208.42.156.2 as permitted sender)
In-Reply-To: <NBBBJGEAGJAKLIDBKJOPAEPDOFAC.noel@devtech.com>
References: <NBBBJGEAGJAKLIDBKJOPAEPDOFAC.noel@devtech.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <F2B959C2-3BC2-4137-9752-C769DD635001@visi.com>
Content-Transfer-Encoding: 7bit
From: David Blevins <david.blevins@visi.com>
Subject: Re: [vote] Propose OpenEJB for graduation to a TLP
Date: Mon, 30 Apr 2007 09:45:57 -0700
To: general@incubator.apache.org

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