Example: Perform Technical Feasibility Exploration
This example briefly describes a technical feasibility exploration scenario.
Relationships
Main Description

Consider a Rent-a-Car example.  The following requirements might be in play:

  • Provide a seamless interface between remote client/server, workstation applications, and 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 screen.
  • Support input and output messages of IMS applications which are pre-defined and fixed format.
  • Make message formatting-related processing transparent to the IMS application, so that the time necessary to develop and test new remote applications is significantly reduced.
  • Support new IMS application features and new data fields to remote systems in a timely manner, for example 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 could be 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 IMS applications.
    • 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.
    • Perform 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 system.
  • 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. Because 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.