To synthesize an exemplar solution that meets the critical architectural requirements, this exemplar may be limited in some way, such as:

• the resulting solution may simply be conceptual,
• the resulting solution may only illustrate some critical aspect of the overall requirements.
  

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.

• This task would be done in parallel with other steps that identify the services that are actually going to be exposed (during Activity: Perform Service Specification).
• The transactions that need to be componentized and exposed need to be identified as part of Task: Existing Asset Analysis but also in the context of the overall Activity: Existing Asset Analysis process and later refined during Activity: Perform Service Specification.
• Elements of these Architectural Proof-of-Concept decisions and considerations relate back to both functional and operational aspects of the architecture.

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 a connector.
• 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.

Example

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 screen.
• 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 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.
  • 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 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. 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.