A highly scalable multi-tier J2EE based architecture presented on the picture was built by the author for telecom and IT management as a set of extensible services-frameworks with ability to add/customize services run-time.
Reusable code should be well understood and perfectly commented.
The examples below can give an idea about candidates
for reusable services and shared data.
Tier 1 Client Tier communicates via XML based service API, client can be:
-a partner application running on a workstation
-Web Browser with JavaTM Applet
-Wireless device with embedded WML browser or VoiceXML interpreter
-Java card technology device
Tier 2 Web Server Container with J2EE Servlet and JSP engines where servlet is responsible for session tracking and request distribution, and JSPs provide presentation layer back to the client.
Tier 3 worker beans providing services
Services-Worker beans can be (not necessary) implemented as EJBs to gain advantage of security and transaction monitoring services provided by EJB containers
Tier 4 Connectors to Data Sources, Remote Systems, and Devices
A Data Source model was created to describe multiple HR/ER data sources with their types, rules, and structure using XML descriptors.
A unified approach was used to connect to all data sources using Java Naming and Directory Interface (JNDI). A Data Source interface was implemented for RDBMS, LDAP, file structures, directory services, and DNS systems.
A master controller is created to describe a set of operations on telecom systems.
Telecom XML based device control API is implemented for drivers providing control on legacy PBX, IP, and wireless communication systems.
Tier 5 Data Sources and Remote Systems
Telecom systems like PBXs, Voice Mail Systems, etc, other remote devices, and systems.
Data connectors and device controllers (Tier 4) communicate to Data sources, remote devices, and systems via XML based Device Control API
Back To Basic Steps
5. Recognize Reusable Services and Shared Data
Look for reusability from two points of view:
within an application and throughout multi-application environment.
Security Services
Taking into account multi-platform implementation
this service belongs to the client or presentation side
and is implemented differently for different platforms.
For example it's reasonable to use for UNIX systems
"whoami" - UNIX system call to return System User ID.
For Windows systems an additional LOGON - dialog window
can appear prompting a user for USER ID and PASSWORD.
If PASSWORD matches USER ID, this implementation
also returns User ID.
This service is used to cache some database tables
into memory for multi-user usage.
This is a good place to recognize data that can be shared
in multi-user application.
This service is executing SQL statement
stored dynamically into the Text Data and
passed as an argument to the method.
It returns result data from database in a format
presented by another input argument.
5.2 SHARED DATA
Two types of shared data should be recognized:
- client shared data,
data shared between layers or screens within the application.
This kind of data can serve as common interface and
should be stored (cached) on the client side.
Each user/client works with its own set of the client shared data.
- multi-user shared data,
data shared by many users,
like statistics or short database tables.
This kind of data should be stored on the server side
as a unique copy that can serve to all the users
running this application.
It is recommended to define specific classes for shared data and
introduce proper methods operating on the data.
Statistics can be an example of such a class.
Statistics being organized as shared data gives inexpensive
opportunity real time review an application usage
Reusable Services operating on Statistics give an idea about Multi-User
shared data usage. Statistics services can be fired when any user starts
or closes an application. Then the major results are immediately available
to all the other users on line.
It helps to collect Statistics (shared data) on how many users
are looking into the application and for what reason for example
for review or to modify data.
Client shared data operations are expect to be more specific to
an application and not necessary (but willingly) are reusable.
5.3 SCREEN REUSABILITY
Components of User Interface or Widgets, like data fields,
buttons and others also can be considered as source of
reusability especially for a high density screens.
Current tools allow dynamically change widget state
from visible to invisible, from active to inactive,
change color, label name and so on.
This technique helps to make widgets multi-functional and reusable.
Back To Basic Steps
![]() |
8. Use Style Guidance while coding and review the
code regularly. (It also keeps proper communication level for a team). Only well understood and perfectly commented code can be reused. |
"The Elements of Java Style" book describes more style details. It requires to provide full JavaDoc comments on all classes, methods, and interfaces. Comments should include description, parameters, return value, and exception tags if needed. Example of usage is also welcomed. Use blocks in if-else, switch, and all looping constructs, it makes alterations fail-safe. All cases and defaults get break statements for the same reason. It is preferable to use StringBuffer for strings that get modified instead of using s +=. Use String s = "hello"; // instead of String s = new String("hello");. Do not use "try-catch" blocks to prevent run-time exceptions, but always use a proper logics instead (see above).// StyleExample package its.examples; // Internet Technology School packages import its.gis.ITShape; import its.util.Tree; /** * A class implementing Java Style Example. * The purpose of the class is * How to use this class: ... * Example: * @version 0.1 September 10, 1996 * @author Jeff.Zhuk@JavaSchool.com */ public class StyleExample extends ITShape { // class data members private Tree[] dataTree; // array of objects // .. More data // class methods with JavaDoc headers /** * getDataTree(int iIndex) method returns one element of array * @param iIndex element index in the dataTree[] array * @return dataTree if available, return null in other cases */ public Tree getDataTree(int iIndex) { if(iIndex < 0 || dataTree == null || dataTree.length < iIndex) { // check first! return null; // to prevent run-time exceptions } return dataTree[iIndex]; } // more methods ... } // end of StyleExample class
Tuning performance does not necessary means re-design.
Client-Server architecture (if properly designed) allows
to re-distribute or partition services to optimize the load and
to improve the performance.
Java based architecture is a perfect one such re-partition.
Back To Basic Steps