In this first in a series of article, you will learn about fundamental exception handling approaches for EAI applications with real-time scenarios. You will learn about the usage of exception handling guidelines, EAI system behavior, and best practices in the direction of implementing a generic EAI exception-handling framework using an industry accepted Web service framework.
For this simple application, the exception handling catches application errors and notifies the users with relevant error messages. Where the EAI application is concerned, the exception-handling framework plays a bigger role and the degree of applying the exception handling approaches is higher because many systems are involved in the entire application workflow. So, you need to think about all aspects to make a successful exception-handling framework.
The objective of any exception-handling framework is to identify critical breakdown points and overcome from such system breakdowns. To do so, you take alternative notifying or resolving processes in the direction of making the robust system in terms of reliability and high availability.
Exceptions can happen at any point in the application states; for example, during process initialization, in the middle of the process, or it may be at the end of the process.
The exception handling framework should be designed in direction of diagnosing/monitoring of each of individual system transaction, analyzing all possible pitfalls (cause of the system failures) for each transaction and include corresponding preventive action processes in the exception handling framework itself to avoid all analyzed breakdowns.
Following are the stages of the EAI Error handling life cycle.
- Monitor/Diagnose each individual transaction of the developed/deployed EAI application.
- Analyze predictable events that cause system/application failures.
- Identify preventive measures for each analyzed pitfall.
- Design preventive actions process to take into the derived alternative flow when the exception happens.
- The exception handling process life cycle is endless and proportional as and when new enhancements are added to the System.
- When new features are introduced in the system, apply the next degree of exception handling for newly included features:
- If (system performance is better than earlier), add the next level of error prevention/error handling mechanism.
- If (system performance is degraded by newly added features), analyze the newly enhanced features with respect to already defined Exception Handling Framework. If there is need to incur the new changes, redefine the Exception Handling Framework by starting from Step 1.
Repeat the above steps to incrementally tune the exception-handling framework until a fine-tuned SYSTEM is created in terms of consistency,durability, maintainability, reliability, stability, and high availability.
Overview of Web Services Exception Handling Framework for EAI Applications
Figure 1: Overview of Web Service Exception Handling Framework
The EAI application works at both the data level and business process level and assists in sharing data with many systems. The EAI application provides connectivity with different business systems and sharing of data depends on the nature of the data that is being exchanged across the systems.
The EAI application maintains a centralized repository to store data for each of the connected systems. Use this meta data to track all the live systems and reconnect the system as and when connection failures happen.
The primary feature of Web services is to provide the connectivity among disparate systems by following uniform standards such as WSDL, SOAP, UDDI, and XML.
Web Services or Service-Oriented Architecture provides a generic centralized exception handling framework that can be fitted into any EAI application.
The key inputs for the error handling framework are the fundamental requirements of given EAI application, the flow of execution of each requirement or task, the expected result of a given task, and how the application is connected/deployed with the different participating systems.
The behavior of the EAI exception handling framework is more or less similar to other exception handling framework; none other than the fundamental EAI application property notifies the connection failures with the relevant process state information.
Web Services Exception Handling Framework Guidelines for EAI Applications
The following are the most commonly used principles of any exception handling framework:
- The first step to designing an exception handling framework is considering all possible real-time scenarios and respective blocking factors to implement such real-time scenarios.
- Analyze the impact of each blocking factor by drilling down the problem.
- Categorize the blocking factors (exceptions or bugs) as critical, medium, and low, based on the severity of the problem.
- Tune the application architecture until the number of blocking factors is minimal. The number of blocking factors or bugs should be zero for a successful application.
- Define the alternative flow for each blocking factor and avoid SYSTEM blocking throughout the process execution.
- Define a notification mechanism for each system failure by giving a relevant message (error messages) to track the system behavior.
- Track all of the process execution states and generate in error log file where and when the application is blocked by exceptions.
Design Approaches for the EAI Exception Handling Framework
The design of a Web services exception handling framework is influenced by the architecture of a given EAI application. The primary behavior of the framework is to provide a uniform exception handling mechanism for all general exceptions, such as connection failures among the disparate integrated systems, connection timeouts, availability of data, network failures or port occupation, failures at data conversion (invalid data format), and many more.
The robustness of the EAI application depends on how well the exception-handling framework is implemented with a centralized notification control to track all the captured defects of the entire integrated system.
Figure 2: Stack of EAI Application Properties
Now, examine the common properties of the EAI architecture and Web Services architecture, in the direction of making a generalized service-oriented, exception-handling framework that can be fitted to any EAI application.
Connectivity: The status of the connections between host systems will be monitored and notified whenever a failure happens.
- Usage of fault tolerant hardware and clustering enabled application design helps to avoid connection failures to a maximum extent.
- Connection from one system to other system is maintained in a metadata repository.
- The centralized or metadata repository acts as a notification engine when the connectivity of integrated systems fails due to network problems and helps to reconnect with the failed system. The scheduler plays a role to ping up the connected or disconnected systems in the EAI workflow to monitor the connection timeouts and notify as and when the connection failed.
Consistency: Define an error code for each blocking factor and associated with the relevant error message.
Flexibility: Able to add, delete, or modify the components of the exception framework. The framework should be able to incorporate or accommodate new features as per business requirements are changed.
Message and System Monitoring: EAI application exchanges the data in the message or event-based format. The message level integrity resolves many integration level problems. The message workflow provides the necessary state management to complete a business process in the integrated environment.
Stability: Include state management into the exception framework to bring the system back to a normal state, even if exceptions are raised.
Event-Based Approach: Apply trigger or event-based (on and off) methodology in the exception handling framework to overcome performance bottlenecks (slower system execution).
Reliability: Ensures the keeping of process data when an exception is raised in the middle of process execution.
Notification of error events: An error message should describe the cause of the problem and state where it failed:
- The error log should show the complete path of execution before it failed and the error message should describe the cause of the problem and state where it failed.
- Handled exceptions should be published. When exceptions are handled, the error data should be published to a system log and/or to the user.
- Error code and errors message mapping:
- All automatic workflow activities should be tracked to ensure they are started and completed within an acceptable amount of time.
- Tracking of the notification should be in place and produce reports for scheduled intervals of time.
State Management: Maintain process state and process until process is successfully executed or aborted at the middle of the process state; in other words, the request is timed out or the connection fails.
- Remove the process data from its storage buffer (file or database) when a transaction is successfully committed or executed.
- Roll back the process data (changes done by the process to avoid the duplication of data)
To achieve commit or rollback of the transaction, the latest process state is captured and maintained in the persistence way. This captured process data helps identify and correct the process failure.
- Use the process data to continue the process workflow where it is left out. To achieve this task, the latest process state is captured and maintained in the persistence way.
In this article, you have seen various exception handling guidelines, EAI application properties, and the life cycle of the Web Services exception handling framework. In the coming articles, you will learn about the internal components of a generalized exception handling framework and how these components fit an EAI application.
About the Author
Sridhar Ravuthula is a technical leader with Reliance, India. He was with ONGC, Syntel, and Hewlett-Packard. He has a master’s degree in computer applications. Sridhar has been involved in designing and developing J2EE-based solutions on various platforms. He has worked in flagship product development, HP e-speak, and HP Bluestone (HPAS).