A major challenge in integrating disparate systems is to provide a unified security model. Single sign-on across internal application and asset boundaries is required. Until recently, information technology departments have maintained high levels of control
over the environment of both servers and clients. With information assets increasingly being accessed over the Internet, there is additional complexity associated with maintaining security.
When designing distributed enterprise applications, availability and scalability are fundamental considerations for implementing automated change in use patterns and system configuration. A system which requires any redesign, recoding, or redeployment to achieve either availability or scalability will limit flexibility and diminish performance.
Web Service Development Approaches
There are two general approaches to web service development:
top-down and bottom-up.
The top-down is based on the web service interface and XML types defined in WSDL: Web Service Definition Language and XSD: XML Schema Definition files. The implementation of the web service is designed using a WSDL editor or utility to create a WSDL file. The Web Service wizard then can be used to create the web service and skeleton Java classes for adding the required code. The skeleton implementation to interface is modified with the business logic. The top-down approach provides more control over the web service
interface and the XML types being used. It is used for developing new web services.
The bottom-up is the creation of a web service created based on the existing business logic in JavaBeans or EJB. A WSDL file is generated to describe
the web service interface. The bottom-up pattern is used for exposing an existing function as a web service. No XSD or WSDL design skills are required for rapid installation. When complex objects are being used, the generated WSDL might be difficult to understand and less interoperable.
Logging: WebSphere Application Server
WebSphere Application Server includes multiple modes of logging for problem determination.
Basic logging and tracing is the default mode. WebSphere Application Server writes system messages into a text file which can be examined remotely using the administrative console or locally with a text editor. The Log Analyzer tool provides interactive viewing and analysis.
The Showlog tool converts the content of the service log to a text format.
HPEL: High Performance Extensible Logging stores log and trace data in a proprietary binary format. Log and trace performance has been enhanced with HPEL. Log and trace events are stored only in a single location. Log
events, System.out, and System.err information is stored in the log data repository. Trace events are stored in the trace data repository. Repositories are not shared across processes. Each server process has its own
repositories and text log file. As processes are writing data, the server environment synchronization will not be required. Data is not formatted until it is viewed. Log and trace data is stored in a proprietary binary format and formatting
is through the LogViewer tool.
In WebSphere Application Server, the server dump command is used for diagnosing problems on a Liberty profile server. The result file obtained from the
command contains server configuration, log information, and details of the deployed applications in the work area directory.
Log and trace data is buffered prior to being written to disk.
Qualifying a Training Request
The client is using EJB 2.1, and WebSphere. The course will need to provide examples using WebSphere Application Server. Depending on the experience of the personnel it may be a necessary to review networking concepts and Java fundamentals. Java Database Connectivity needs to be taught.
The WebSphere and Rational curriculum has been designed for teaching application developers how to implement standardized ways for accessing middle-tier and back-end services: database management systems, transaction monitors, remote debugging services, and shared applications. Case studies, code snippets, and sample programs present the issues and trade-offs associated with building web services. Guidelines are providing for designing web services and moving to a service oriented architecture.
The client selects the subject matter: data structures, exception handlers, the Java I/O package, and input/output APIs.
Client-specific Examples and Exercises
The examples and machine workshops present:
- How to develop session beans.
- Developing entity beans for accessing and controlling the database associated with the application processing transactions.
- EJB Query Language for querying a database and retrieving specified information.
- The development of message-driven beans.
- Optimizing the web site performance.
WebSphere Application Server configuration concepts
are presented in conjunction with application deployment.
Best Practices and Guidelines
WebSphere Web Container
If JSPs are not pre-compiled in an application, the initial invocation of JSPs will take longer to complete. Pre-compiling JSPs also will reduce compilation related disk operations. JSPs can be pre-compiled at different
times in the deployment process: 1- RAD: Rational Application Developer or other development tools. 2- The Admin Console when deploying an application.
Once the application has been deployed, a JSP batch compiler tool still can be run. The URL invocation cache contains information for mapping request URLs to servlet resources. A cache of the requested size is created for the worker threads available to process a request. Each JavaServer Page is a unique URL; the default size of the invocation cache is 50. If more than 50 unique URLs are actively being used, then the size of the invocation cache should be increased.
EJB Container Cache Size and Cleanup Interval Tuning
The cache size specifies the number of buckets in the active instance list within the EJB container. In order to maximize performance, each bucket in the table should have a
minimum number of instances assigned. Balance performance and memory by setting this value to the maximum number of active instances expected during a typical workload.
The cleanup interval specifies how often unused cache items are removed; the default is 3000 milliseconds. As the cache size increases, the recommendation is to increase this parameter.