Thanks for the reply, Mark. What we are looking for is a free J2EE compliant
app server to use and develop against now, with the opportunity, if need be, to
move to a commercial app server if performance requires it and the free app
server isn't providing enough performance.
To that end, we have come up with a list of requirements. Some of these
requirements are obviously satisfied ("free" comes to mind) but others I just
have no idea about.
Would somebody be willing to comment on how jBoss addresses these requirements
(or doesn't address right now)? Again, thank you very much for your time.
Corporate Requirements:
--------------------------
1. Cross-platform: Runs under WindowsNT, Windows2k, Solaris, Linux, and
preferably other Unix varients
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.
3. Scalable: Must scale from a single process to multiple processes on a single
machine to multiple machines.
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.
5. Servlet support: To minimize any code porting, Java Servlets must be fully
supported.
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.
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.
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.
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.
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.
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.
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.
7. Implicit multiclient support: An app server needs to concurrently route
requests from clients and appropriately channel those requests to components.
8. Implicit component location transparency: Clients of components should not
know where the components themselves are located.
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.
Optional Features for an Application Server:
---------------------------------------------
1. Intelligent load balancing
2. Transparent fail-over
3. Presentation layer seperate from business layer
4. Support for development environments
5. Support for component management
--
Travis Jensen <[EMAIL PROTECTED]>
"Writing with Light" http://www.digijen.com/travis/wwl
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
