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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
