- Business-IT Challenges and Issues
- IT Personal-Application Challenges and Issues
- System Design Alternatives
- Changing an Existing Application to a Transaction Server
- Wrapping an Application
- Transaction Server and Middleware
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Changing an Existing Application to a Transaction Server
When considering option "C" in Figure 3, the following questions come to mind:
){kind=link}
What exactly needs to be changed in the existing application?
How can the existing application be bundled with new technology?
What will be the impact on the business process?
In Figure 3, the presentation layer is communicating directly with the transaction layer. In that solution, changing the existing application would be considered as a process of elimination. Obviously, the existing presentation code, which builds the screen message, has to be eliminated because we only need to send the row data through new presentation layer. Most security-related codes also need to be eliminated from the existing code because the user will be authenticated at the new presentation layer. The transaction server requires the security information only if the application itself is doing additional security checks, perhaps giving different users access to different customers. The ideal solution for this kind of security situation is to add extra fields for the user and role identifiers to the messages for the transaction server. Also, in many applications, the menu guides the application, but now the new presentation layer does all the guiding, and the transaction server only processes inquiries and updates transactions without any regard for the ordering.
Unfortunately, many existing online transactions processing applications do have ordering dependencies. Analysts, knowing that the terminal screens would be submitted in a certain order could perhaps exploit this fact. For example, once the screen adds a new customer or finds an existing customer, it adds a new order. The customer identifier might be stored in local storage and used in the new order transaction without doing any further checks.
Storing the customer id in local storage is an example of session state. The session id was captured based on the terminal id. Typically, the transaction monitor will have the facility for storing a small amount of data in the output message. This data, however, is not sent to the user; it is retrieved by the application for the subsequent input from the same terminal.
Imagine if we lose this session in the middle of the transaction. The user must restart the session from the beginning or else the system will take the user where the session was lost; hopefully, you find the user in the database. When we implement the new user interface, we might not want to move forward with this recovery strategy. In this example, the simplest solution is to store the customer id in the client machine and pass it as a parameter to the transaction server. This simple resolution will allow the client to go straight in and carry on processing where they left off.
Ordering dependencies are one example of storing state. Two other common reasons for storing state are security and temporary data gathering. The temporary data storage strategy can be used in the Order Application until the final command has been sent so that all the information can be sent immediately to the database in one transaction. Another solution for the problem described in the previous section without the need of two-phase commit when one large message from the web may be broken down into several small messages and then one of the messages from that fails to reach the transaction server. The solution is to take all the data and create a single transaction and call the existing code within one transaction so that there is no need left to collect data in the session state. However, if there is still a problem in resolving issues such as the one described above, the session data should be stored in the database. You should be able to wrap a number of small transaction types by separating menu-driven programs, security and session state.