Travis Jensen wrote:
> > > 2. Free: Because of the various types of "free" licenses, we need to evaluate
> > > the license of whichever product we choose to make sure that it is compatible
> > > with out business model.
> >
> > GPL. We are applying it in a rather non-strict fashion though. Apps are
> > not GPL.
> >
> 
> I hate to get caught up in legaleze, but can you determine how the license is
> enforced?  

The first rule is that we don't want to get to that point in the first
place. A simple reminder to anyone that breaks it should be enough.

If someone, despite any such notices, would continue, it's very tricky
since jBoss the organization is not a legal (/registered) entity. I
don't know the details of how that would work, and hopefully I/we will
never have to worry about it.

> Don't get me wrong, I am a huge proponent of open-source, but I can't make
> my company give away their source code; and if a license looks remotely like somebody
> could make them give it away, that is dangerous.

Here is where I want to be very explicit about type of source is
required to be given away to the jBoss project:
1. Any application code (i.e. beans) are NOT covered
2. Any components that can be plugged in as pure JMX components are NOT
covered
3. Any components that can be plugged in to the jBoss container but are
accessed through glue code is NOT covered
4. Code that modifies or enhances the way the jBoss container or any of
its components work IS covered.

If you add clustering: we want it, in the same way that you might be
interested in any clustering code I/Telkel comes up with. 

I think Marc put it well in the PGO description: this is coopetition. We
are competing with each on making application servers, we are competing
on applications built ON TOP of an application server. Since we have a
common need, an application server, we cooperate on that, and compete
with the applications on top of that. 

Do you see my point? Is this a problem for your company?

> > > 3. Scalable: Must scale from a single process to multiple processes on a single
> > > machine to multiple machines.
> >
> > This we don't have right now.
> >
> 
> Any idea on a timeframe for that?

No. It would take a fair amount of prototyping, testing and
brainstorming, all of which are more or less impossible to put a
timeframe on.

Anywhere between tomorrow and before next J1 would be a safe bet though
:-)

> > > 4. Java-based: Must be able to transparently run Java code.  This does not mean
> > > that the app server itself is necessarily written in Java, just that it has full
> > > Java integration.
> >
> > Check. The reliance on JMX makes it very easy to integrate with other
> > Java code.
> >
> 
> So is all cross-component communication handled via JMX?  If yes, how does that 
>affect
> performance?

All communication between JMX components in the server must be through
JMX. There is some overhead, but the gains are more interesting I think
(e.g. the ability to update/replace components on the fly). I don't
think that this kind of communication is going to happen very often
though. Also, plesae note that EJB components talking to EJB components
does not use JMX for example. They use the optimized JRMP invocation
thingy.

> > > 5. Support for component management
> >
> > Vague requirement. What would this translate to in terms of
> > functionality?
> 
> I guess a better way to phrase this is will jBoss support JMX?  Having a standard way
> of managing beans, especially if it can plug in to SNMP, is a huge win on a complex
> system.

jBoss is about as JMX as it gets: the "spine" is an MBeanServer. All
functionality is provided as JMX components (you can even take the EJB
container component and plug it into any other JMX server).

> And the final question.  I'm looking at jBoss and Enhydra.  Tell me, what do you see
> as the primary things that differentiate jBoss from Enhydra and make it a safer bet
> for development six months from now?

Our EJB container architecture is better, largely because I think we
have a better understanding of EJB. I regularly check the Enhydra
mailing lists, and it is kind of sad to see the kind of level they're
at. Not even close to the discussions we have here, and I think it will
take them quite a while to get to where we're at now. This is of course
only my opinion though :-)

Any more questions, just fire 'em away.

/Rickard

-- 
Rickard �berg

@home: +46 13 177937
Email: [EMAIL PROTECTED]
http://www.telkel.com
http://www.jboss.org
http://www.dreambean.com


--
--------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Problems?:           [EMAIL PROTECTED]

Reply via email to