Hi!
Travis Jensen wrote:
> Corporate Requirements:
> --------------------------
>
> 1. Cross-platform: Runs under WindowsNT, Windows2k, Solaris, Linux, and
> preferably other Unix varients
Check.
>
> 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.
> 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.
> 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.
> 5. Servlet support: To minimize any code porting, Java Servlets must be fully
> supported.
Tomcat/Catalina will be integrated.
> 6. Non-proprietary: In order to prevent us from being locked into a single
> vendor, any app server chosen must either use non-proprietary standards or have
> proprietary components available in such a way that they could be integrated in
> other systems.
Check. No proprietary code needed. If you do use any jBoss components
directly they are easily portable by virtue of being JMX components.
> Necessary Features for an Application Server:
> -----------------------------------------------
>
> 1. Support for a standard distributed component model: By supporting a standard
> distributed component model, we are no locked in to a single application
> server. However, that distributed model should have no or very little overhead
> for intra-VM calls. In addition, by using a standard component model, we are
> more likely to be able to leverage code that others have written for standard
> tasks.
EJB is supported. Intra-VM is optimized.
> 2. Implicit distributed transaction management: Allows you to perform
> transactions (ie: can be rolled back) in a distributed environment so operations
> can be performed in a deterministic manner. This feature is absolutely critical
> for creating features such as a web-based shopping cart. Not every request
> should be transaction-oriented, though.
This has not been fully implemented yet. It is very high on the priority
list though.
> 3. Implicit security: Security should be fully configurable while remaining
> transparent to the applications using it so the application can remain secure
> while freeing developers from thinking about security concerns. We should be
> able to provide our own security provider if necessary.
Not implemented yet. Also very high on the priority list.
> 4. Implicit resource management and component life cycle: Resources such as
> threads, sockets, and database connections should be managed and pooled by the
> app server. In addition, the life cycles of any components should be managed by
> the app server. Both of these reduce the need for standard book-keeping work
> that often acompanies development.
Check.
> 5. Implicit persistence: The app server should provide for persistance of both
> objects and the state of the system. This reduces work in developing database
> interaction and can provide increased failover reliability. Ideally, this
> persistance would be configurable, allowing us to determine the final object
> store.
Check. JAWS is pretty neat in this regard, and will hopefully evolve to
support EJB 2.0 CMP.
> 6. Implicit remote accessibility: In order to provide for a distributed
> environment, an object must be able to be transformed from an intra-application
> object to a networked object without added development, freeing developers to
> think about the business logic and not the network details surrounding it.
Check.
> 7. Implicit multiclient support: An app server needs to concurrently route
> requests from clients and appropriately channel those requests to components.
Check.
> 8. Implicit component location transparency: Clients of components should not
> know where the components themselves are located.
We do not yet support the application client java: namespace as
described in J2EE 1.2. Should be trivial to add though since we already
have it working on the server-side.
> 9. Naming and Directory Services: An app server should provide naming and
> directory services in order to find components on the network and provide access
> through a standard mechanism that does not tie us to the application server.
We have our own hierarchical JNDI implementation. Check
http://www.dreambean.com/jnp.html for some more info.
> Optional Features for an Application Server:
> ---------------------------------------------
>
> 1. Intelligent load balancing
>
> 2. Transparent fail-over
Not present due to lack of clustering. When this is done (and I have a
couple of really out-there ideas on how this should work) it will be
top-notch.
> 3. Presentation layer seperate from business layer
Vague requirement. What would this translate to in terms of
functionality?
> 4. Support for development environments
Some IDE�s will be integrated. Hot-deploy definitely makes the dev-cycle
extremely short.
> 5. Support for component management
Vague requirement. What would this translate to in terms of
functionality?
That's about as correct as it gets I hope. Feel free to send more Q's
regarding this. I guess more than you are wondering about these issues.
regards,
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]
