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 <[EMAIL PROTECTED]> wrote:
On Apr 24, 2007, at 12:46 PM, Brett Porter wrote:
> On 24/04/07, Noel J. Bergman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
