Foundation Facility

JMS
Java Messaging service offers a unified wrapper over queuing mechanisms. The framework wraps the JMS implementation and provides methods for applications to use this service without knowledge of the underlying queuing mechanism or the JMS API. The JMS API offers a asynchronous send and receive mechanisms and also a synchronous send and receive mechanism for application clients. The synchronous implementation is a convenience implementation which calls the send and then the receive methods with an appropriate timeout. The mechanism uses the JMS correlation id to associate the request and the response. The framework also implements a wrapper over a JMS Topic thereby allowing an application to work in a publish subscribe mode.
Logging
This supports for reporting application events into persistent storage areas. Logging provides precise context about a run of the application. Once inserted into the code, the generation of logging output requires no human intervention. Second, log output can be saved in a persistent medium to be studied at a later time.
Rules
It provide flexibility to application design and development by externalizing dynamic business logic. As some areas of the business are more susceptible to change than others. It is important to therefore have a mechanism that allows an application to identify areas that are likely to change and externalize the logic contained within them. This changes should be managed is a such a manner that there is no to less development effort required. It uses code generator to generate rule classes. Rule classes run in the same address space as the application program. This enhances performance as rule classes run in the same address space and use the same thread of execution, they share the transaction database session context for data. This avoids reads from database for data that is already loaded. Rules can also be dynamically changed by integrating with dynamic class loader.
Dynamic class loading:
This facilitates deployment of business rules dynamically without stopping the application server. Rules as mentioned above are business logic that changes frequently and needs to be deployed on the application server without restarting the application server. Rules are deployed as jar files in the application server, any changes to the rules would negotiate a re-deployment of the jar files. Currently it is not recommended that the hot deployment option of the application server be used. This is because the application server vendors claim that it might cause potential synchronization problems with the deployed application and might cause deployed applications to be deleted or modified incorrectly.Custom class loader load classes directly from the disk. It scans a pre-defined area on the file system for changed files based on time stamp. Clients already in middle of a method call will continue to use the old class, while new clients will receive an object from the changed class. It checks for modified classes on configurable time based interval.
Configuration:
It supports for retrieving of application parameters defined in properties file. It synchronizes with the changes made to the application parameters while the application is running. This component uses caching and logging architectural mechanisms. Configuration allows for providing set of properties in a different properties file to
Helpers
The Framework offers various helper functions to facilitate the building of framework components. These components are expected to be re-used across various other sophisticated framework facilities or components.The following helpers are available as part of the framework. These facilities are implemented as helpers as any improvements to these facilities can be done in a central place benefiting all framework components that use them. For example, if there are changes to reflection helper to leverage performance enhancements to the next version of J2SE, then all components will benefit from the same. Similarly the XML Helper wraps the DOM implementation of Xerxes and provides an easy to use interface. The XML Helper includes some significant performance enhancements in the way commonly used XPath (/Customer/Name/) expressions are evaluated. It uses a custom mechanism for these kind of expressions instead of the much slower XPath API. XPath API is still supported for the complete XPath specification.
Error and Exception Mechanism:
This architectural mechanism handles application errors and loggs them as per standard strategy. Error handling supports for multi-lingual error messages for the same error codes. Two named exceptions viz FrameworkException and BusinessException are provided to be used to denote any application errors. Unique error code is assigned with each exception to identify the error.
Service locator
This is a deviation of the standard service locator pattern. It provides transparent object access to applications or other framework components. The service locator abstracts the service discovery process. This discovers a service based on a set of configuration parameters provided. This will then return an object of the service based on the parameter defined. The service locator handles the discovery of JNDI services apart from specific services like EJBs, JMS handles and POJOs. It caches JNDI resources to avoid lookups for each invocation.
Alert
This architectural service provides mechanism for sending alerts for an event. Events needs to be registered with alert service. Event handlers are implemented that handles the event. Support for alerting by SMS and Email is provided using SMS and Mail helper architectural components. Events have information as required by it’s event handler. Client provides those information in the Event and does not need to know about the recipients and mode of alerts. Event handler identifies the list of recipients and modes of sending alert. Alerts are sent asynchronously where client does not wait until alert is sent.
Reporting for batches
This architectural service is a wrapper over third party, OZ reporting, tool and provides option to plug-in another reporting tool in future without change in the client code. OLTP reports will continue in the same style as the existing KB system. Mainly this service is used by batch. Report service supports two modes of execution, synchronous and asynchronous. In asynchronous execution mode, the client request a report and then poll for the status based on the report task ID that was provided when requesting a report. In synchronous execution mode, the client waits for the completion of the report.
Mail
Mail component provides facility to send an email. Mail shields client from internals of sending email. Client is not required to know about the details on how to send mails. Mail component currently is used by Alert. Mail component currently inserts a record in a table owned by e-business team. E-business team finally reads records from the table and sends mail using their existing mail gateway.
SMS
SMS component provides facility to send a SMS. SMS shields client from internals of sending SMS. Client is not required to know about the details on how to send SMS. SMS component currently is used by Alert. SMS component currently inserts a record in a table owned by e-business team. E-business team finally reads records from the table and sends SMS using their existing SMS gateway.
Data Compression
Data compression implements a simplified API over the GZIP implementation. This mechanism can be used to compress data being transferred from the channel tier to the application tier or from the client to the channel tier. This mechanism can be used where-in the available bandwidth mandates a data compression mechanism. By implementing a standard compression algorithm, the data compression mechanism allows even third-party applications to compress data.
Charset Conversion
This supports for conversion from EBCDIC character set to ASCII character set and vice versa. Client code need not code for character conversion every time instead they can use this component.
FTP helper
FTP helper assists in listing and exchanging files between two servers. This uses the Apache commons FTP library, but makes modifications to the open-source library by providing support for the IBM mainframe file system. Files are exchanged using FTP protocol where host runs FTP service. This component consists of a convenience GUI which shows the progress of the files downloaded or uploaded. Client can get the listing of files on host system using this component. This component supports DBCS.
File Parser
This architectural mechanism provides a uniform approach for parsing of ASCII flat files. It supports position based and delimiter based file parsing. It returns the parsed file as a domain object thus freeing developer from file IO operations. Provision for returning domain objects after each record is parsed or in batch of records is provided so as to maximize memory utilisation as per the application need. It supports two models for parsing viz push and pull. Push model parse pre-configured number of records and send to the client as domain object. Pull model waits for client to request to parse the file sequentially in batches. Client receives an handle to lazy fetch which can be iterated through to generate next batch of records.
Bootstrap
This architectural component assist in initializing required services or components in application server before any client request can be serviced. It also helps in improving performance by ensuring globally required services are initialized and available when required rather than loading them at the time of request. In the channel tier, where there is a web container, a bootstrap Servlet is used. In the application server, which is not expected to host a web-container, this component uses the custom API provided by application server. Hence this component is coupled with application server and is currently available for use in IBM Websphere application server for the application tier.
Data Access Service
This architectural mechanism allows access to the persistent store. It is wrapper on Hibernate ORM that provides XML based mapping of objects to relational mapping. It uses IOC (inversion of control) to keep the connection handles encapsulated from a developer and internally uses a reference counting mechanism to finally close database connection. It throws named exceptions to flag application developers of exceptions that can be handled like no data found.
Batch-Shared OLTP
The framework includes a high performing batch framework. The batch framework will provide application developers a platform to assemble business components to be used in a batch mode. The batch framework provides abstract classes for batch application development. The batch framework uses JMS to stream batch jobs. The batch framework does not use custom threads, but rather uses JMS as the threading mechanism to achieve parallelism in a batch job. A batch job can be distributed across not just processes (JVMs) but across servers (or machines). This provides a lot of flexibility in distributing a job. A batch job can therefore be run on the same server as the OLTP or can be run on a different server. It is also possible to introduce new servers for just batch processing, thereby improving the scalability of the batch framework.
The framework provides an abstract batch data class, which can be extended to set the data for the batch process. The developer therefore needs to extend the class for the batch data. Once the data set has been coded for a particular batch process, then the application developer will need to map the batch data set with the input for the process component that needs to be used for the batch process. To actually execute the batch process, the application developer will need to register the batch process using the batch processing administration GUI provided.
PL/SQL Batch Process
The batch framework also provides a PL/SQL version of the batch framework. The PL/SQL version does not share the OLTP process components or the business common services, but provides a simple high performing batch framework in PL/SQL. PL/SQL offers a “near data processing” batch framework. This framework will provide a high batch throughput on a lower system configuration due to the inherent benefits of processing near the data. This framework will need source code duplication and will increase the maintenance effort of the application. Though this will increase the maintenance effort, this framework cannot be written off as it provides a very high batch throughput. For extremely time critical batch processing, this framework may need to be used. The actual usage of the same will depend on the specific requirements for the application.