The Architectural Proof-of-Concept takes input primarily from Task: Existing Asset Analysis and takes into account the Concept: Service Portfolio defined by Activity: Perform Service Specification.
Also, when dealing with existing applications, the following items need to be examined and considered:
Exception Handling: Need to understand how the exception handling works today. In batch processing, when
exception occurs, the program abends (abnormally terminates) and produces a core dump. The programmer is required
to look at the core dump and figure what needs to be done. This may not be acceptable. One would need to figure out
what needs to be done, for instance how to integrate with exception handling framework.
Process and Data Distribution: We need to examine where the data and process are executed. CICS applications
executing on one machine and may send a request to another machine (also known as function shipping in CICS) or
remote call data on another machine. We may like to consider going directly (JDBC to DB) to remote machine where
the process or data is running, instead of using the connector which goes through the JDBC to DB. That is, it is
more optimal to make native JDBC call to a remote data source, as opposed to going through an intermediary such as
Data Availability: If we have customer file in VSAM which requires, say, a 4 hour maintenance window,
then we can't support 24/7 customer service. We would need to consider a new storage solution.
Authorization/Authentication: Many legacy applications have the authorization and authentication mechanisms
in the application code. This would require migrating user access management to Federated managed environment
supported by best practices.
Staging Delays: Typically batch programs run once a day in the night. If requirements are to run the program
more often, then we will have to modify the schedule program to change the frequency.
The above list is not meant to be exhaustive; it is provided here for guidance.
In the Rent-a-Car example, service realization will need to take into consideration the following requirements:
Seamless interface between remote client/server, workstation applications, and the mainframe IMS applications.
Eliminate "screen scraping" from the remote application point of view. This is to eliminate the need to change
remote application processing, simply because a message is added to a screen, or a field changes positions on a
Support Input and output messages of IMS applications which are pre-defined and fixed format.
Message formatting related processing to be transparent to the IMS application, so that the time necessary to
develop and test new remote applications is significantly reduced.
To support new IMS application features and new data fields to remote systems in a timely manner, i.e. reduce the
time it takes to enhance existing systems.
Elements of these technical feasibility decisions and considerations relate back to both functional and operational
aspects of the architecture. To address the above requirements, the following approach was used:
Message Broker/Integration Broker to handle the message formatting to and from the IMS applications. The message
broker performs the following functions:
Reformat inbound messages (from XML to fixed length format) to a predefined format acceptable by mainframe
Reformat (from fixed length format to XML) mainframe IMS output responses back to an IMF keyword format, to
be processed by the original sending application.
Interrogate an inbound message, to determine if it is in IMF format by checking the message header which
precedes the data payload. The header is in a positional format, and contains several key pieces of
information necessary for IMF to process correctly.
Performs routing and transformation based on contents of the Message Header and IMS Transaction Code. This
IMS Transaction code is required in order to execute the appropriate transaction within the IMS Mainframe
IMS-MQ bridge to act as a conduit between the Message Broker and the IMS system.
The use of the Message/Integration broker greatly reduces or eliminates the need to customize each IMS application to
handle transaction requests from various remote systems. Since most of the message formatting related processing is
transparent to the IMS application, the time necessary to develop and test new remote applications is significantly
reduced. In addition, new IMS application features and new data fields become available to remote systems in a timely
manner, reducing the time it takes to enhance existing systems. This leads to loose coupling of applications, which is
one of the core principles of SOA.