作業: Perform Detailed Technical Feasibility Exploration
This task defines how to develop an architectural proof-of-concept, for a SOA solution, based on existing architectural requirements and risk profile.
目的

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 作業: Existing Asset Analysis and takes into account the 概念: Service Portfolio defined by 活動: 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 application 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.
  • 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.

步驟
決定建構方法

選擇用來建構「證明概念架構」的技術,例如:

  • 建立概念模型
  • 快速建立原型
  • 模擬
  • 自動將規格轉換為程式碼
  • 可執行的規格
  • 將尖峰建構為原型 - 垂直片段穿過各層次

軟體架構師在探查有關問題和解決方案空間的過程中,必須能夠說明這些模型。

選取「證明概念架構」的資產與技術

軟體架構師應該從「作業:架構分析」中指出的資產與技術中,選擇要用來建構「證明概念架構」的資產與技術。

建構證明概念架構

軟體架構師在使用選擇用來進行建構的技術時,就可以用所選擇的資產和技術來建立「證明概念架構」,在專案風險概況所要求的範圍內,滿足對架構極為重要的需求,這些需求是在標準的實現使用案例、設計與部署模型概觀以及軟體架構文件中指出。



內容
前一版
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊
概念