本文发表在 rolia.net 枫下论坛Simple Java Server Application Framework (SSF) Project
(this text file is formatted with tab 2)
2001/02/15 11:39, APAS, Inc.
--------------------------------------------------------------------------------
1. Objective, Overview, Requirements
The purpose of SSF is to provide a set of simple classes that wraps Java's
standard JSDK and probably some other related Java server technologies, so
reducing the effort of servlet development and maintenance.
One of the drawback of standard JSDK is, we need to rewrite or update the
core server should there be an additional service need to be implemented.
The server based on the SSF expected to have the following traits:
a. Easily extendable without having to modify or update the core server.
b. Highly configurable and customizable.
The purpose of this small project is to:
a. Make a design of the framework. The expected document representing the
design are:
- static class structure (plain text file acceptable, graphical
diagram with any methodologies also acceptable, UML preferred)
- dynamic class interaction or process flow is not required,
except if there is some points worth mentioning to demonstrate
the design strategy.
Bottom line is, design is important, but it should be concise with
notes about the design consideration points (i.e. logic, reason,
or even philosophical background underlying the design decision).
The design pattern used is also worth mentioning.
Alternatively the design can also be supplied as notes or comments
on the source code.
b. Write an implementation of the framework. (see Note section)
c. Write one simple demonstration server based on the framework.
(HelloWorld kind of server)
2. Technical Specification
a. Use Java language (JDK1.2SE or later), JSDK (2.0 or later).
b. For simplicity, the number of interfaces representing the basic framework
should be no more than 5, and the total number of classes of the core
framework should be as small as possible. There can be any number of
utility and helper classes as required.
c. The interface for the end user of the server is just like a normal
HTTP servlet, that is HTTP GET method. The server should be accessible
from a normal URL request from HTTP browsers.
d. The SSF should include small number of simple interfaces for representing
a service provided by the server. With these interfaces, if there
is a requirement for new service for the same server, the core server
code should not need to be changed. The developer should simply
write new classes implementing the interfaces. The new classes
could be seen as a plugin or pluggable module/component for the server.
e. The load of the service handler plugin should be dynamic, in the sense
of, the server should resolve the plugin to be loaded in runtime
(upon the coming of a request for a service). Once the server resolve
the plugin class to be instantiated, the actual object should then
be instantiated.
f. The class resolver could be highly dynamic, or simply a lookup to a
configuration file.
g. The service handler object loaded dynamically should use some kind
of configuration/metadata, that possibly comes from properties file-type
or even database. The configuration management could also be part
of the framework.
h. If database is used, then a database manager or connection pooling could
be provided as a part of the framework. Even if the cofiguration
using database is not provided in the implementation, the design of
framework should be adaptive to the future addition of any media
of configuration storage.
3. Examples and Hints
Following are an example of the process flow of server based on SSF kind
of framework:
- user sends a URL from browser, e.g.:
http://hostname/servlet/HelloSSF?service=first&name=anima
- server that extends a class and/or implements an interface from
the framework receives the request.
- based on a hint from URL parameter, create the object to handle the
request dynamically.
simple example of the a flow:
received service parameter has a value of 'first', use this value as
a key for resolving the class name.
If factory pattern is used, then the key could be passed to a factory
and the factory would return an object.
- the server then simply ask the created object to give the result of
the service request and pass them back to the client.
- on processing the request, the related handler object looks up to
the configuration file to see, what message should be displayed,
e.g. it would find "Hello World, #variable".
- the object then returns "Hello World, Anima!"
4. Resource Guide
www.apache.org has a lot of reusable java open source code. The use of these
reusable classes are acceptable, even encouraged. Tomcat or Avalon project
on Apache is a good example of dynamic and generic system.
5. Notes
The most important points of this project are:
1. The reason underlying the design in order to fulfill the requirements and
the specification.
2. The process flow doesn't have to be like the one given on above example.
Creative idea on how to organize the system dynamics is highly
appreciated.
3. Implementation only serves as a demonstration to the design. The product
quality is not necessary, as rough alpha quality is enough.
4. The usage of advanced technologies are secondary.
5. The basic principle of generic system should be kept in mind:
no hard-coded values, put every system specific values outside
the program so it's easily configurable.
--------------------------------------------------------------------------------
eof.更多精彩文章及讨论，请光临枫下论坛 rolia.net
(this text file is formatted with tab 2)
2001/02/15 11:39, APAS, Inc.
--------------------------------------------------------------------------------
1. Objective, Overview, Requirements
The purpose of SSF is to provide a set of simple classes that wraps Java's
standard JSDK and probably some other related Java server technologies, so
reducing the effort of servlet development and maintenance.
One of the drawback of standard JSDK is, we need to rewrite or update the
core server should there be an additional service need to be implemented.
The server based on the SSF expected to have the following traits:
a. Easily extendable without having to modify or update the core server.
b. Highly configurable and customizable.
The purpose of this small project is to:
a. Make a design of the framework. The expected document representing the
design are:
- static class structure (plain text file acceptable, graphical
diagram with any methodologies also acceptable, UML preferred)
- dynamic class interaction or process flow is not required,
except if there is some points worth mentioning to demonstrate
the design strategy.
Bottom line is, design is important, but it should be concise with
notes about the design consideration points (i.e. logic, reason,
or even philosophical background underlying the design decision).
The design pattern used is also worth mentioning.
Alternatively the design can also be supplied as notes or comments
on the source code.
b. Write an implementation of the framework. (see Note section)
c. Write one simple demonstration server based on the framework.
(HelloWorld kind of server)
2. Technical Specification
a. Use Java language (JDK1.2SE or later), JSDK (2.0 or later).
b. For simplicity, the number of interfaces representing the basic framework
should be no more than 5, and the total number of classes of the core
framework should be as small as possible. There can be any number of
utility and helper classes as required.
c. The interface for the end user of the server is just like a normal
HTTP servlet, that is HTTP GET method. The server should be accessible
from a normal URL request from HTTP browsers.
d. The SSF should include small number of simple interfaces for representing
a service provided by the server. With these interfaces, if there
is a requirement for new service for the same server, the core server
code should not need to be changed. The developer should simply
write new classes implementing the interfaces. The new classes
could be seen as a plugin or pluggable module/component for the server.
e. The load of the service handler plugin should be dynamic, in the sense
of, the server should resolve the plugin to be loaded in runtime
(upon the coming of a request for a service). Once the server resolve
the plugin class to be instantiated, the actual object should then
be instantiated.
f. The class resolver could be highly dynamic, or simply a lookup to a
configuration file.
g. The service handler object loaded dynamically should use some kind
of configuration/metadata, that possibly comes from properties file-type
or even database. The configuration management could also be part
of the framework.
h. If database is used, then a database manager or connection pooling could
be provided as a part of the framework. Even if the cofiguration
using database is not provided in the implementation, the design of
framework should be adaptive to the future addition of any media
of configuration storage.
3. Examples and Hints
Following are an example of the process flow of server based on SSF kind
of framework:
- user sends a URL from browser, e.g.:
http://hostname/servlet/HelloSSF?service=first&name=anima
- server that extends a class and/or implements an interface from
the framework receives the request.
- based on a hint from URL parameter, create the object to handle the
request dynamically.
simple example of the a flow:
received service parameter has a value of 'first', use this value as
a key for resolving the class name.
If factory pattern is used, then the key could be passed to a factory
and the factory would return an object.
- the server then simply ask the created object to give the result of
the service request and pass them back to the client.
- on processing the request, the related handler object looks up to
the configuration file to see, what message should be displayed,
e.g. it would find "Hello World, #variable".
- the object then returns "Hello World, Anima!"
4. Resource Guide
www.apache.org has a lot of reusable java open source code. The use of these
reusable classes are acceptable, even encouraged. Tomcat or Avalon project
on Apache is a good example of dynamic and generic system.
5. Notes
The most important points of this project are:
1. The reason underlying the design in order to fulfill the requirements and
the specification.
2. The process flow doesn't have to be like the one given on above example.
Creative idea on how to organize the system dynamics is highly
appreciated.
3. Implementation only serves as a demonstration to the design. The product
quality is not necessary, as rough alpha quality is enough.
4. The usage of advanced technologies are secondary.
5. The basic principle of generic system should be kept in mind:
no hard-coded values, put every system specific values outside
the program so it's easily configurable.
--------------------------------------------------------------------------------
eof.更多精彩文章及讨论，请光临枫下论坛 rolia.net