Task: Construct Architectural Proof-of-Concept (SOA)
This task defines how to develop an architectural proof-of-concept, for a SOA solution, based on existing architectural requirements and risk profile.
Purpose

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.
Relationships
RolesMain: Additional: Assisting:
InputsMandatory: Optional:
  • None
External:
  • None
Outputs
Main Description

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

Steps
Decide on Construction Approach

Select the techniques to be used for construction of the Architectural Proof-of-Concept, for example:

  • Conceptual modeling
  • 'Rapid' Prototyping
  • Simulation
  • Automatic translation of specifications to code
  • 'Executable' specifications
  • Construction of  'spikes' as prototypes - vertical slices through layers

The software architect needs to be able to reason about these models, in the process discovering something about both problem and solution spaces.

Select Assets and Technologies for Architectural Proof-of-Concept

The software architect should select, from the assets and technologies identified in Task: Architectural Analysis, those to be used in the construction of the Architectural Proof-of-Concept.

Construct Architectural Proof-of-Concept

Using the techniques selected for construction, the software architect builds the Architectural Proof-of-Concept, using the selected assets and technologies, to satisfy - to the extent required by the risk profile of the project - the architecturally significant requirements as captured in standard use-case realizations, the overview design and deployment models, and the software architecture document.



Properties
Multiple Occurrences
Event Driven
Ongoing
Optional
Planned
Repeatable
More Information
Concepts