上QQ阅读APP看书，第一时间看更新
Integrating SOA into a Legacy Framework
The fundamental idea of enabling a legacy application starts with identifying the core building blocks and access points in the mainframe. There are three main points of integration into the legacy mainframe:
- Presentation Layer: The goal here is to provide some level of service to the consumer to improve the user experience and extend access to other applications through the front-end. The following figure shows that we open up the interface to the legacy system via screen adapters. So, we do not change any legacy code and simply drive the old system with a newer looking front-end.
- Business Layer: Simply stated, this is wrapping of a procedure call with an SOA service. As we will see in the hands-on case study, this can really open up a legacy application for re-use and agility. This can be a nontrivial task. As with any legacy application (mainframe or otherwise), business processes are often not discrete, standalone services. After years of development, we usually end up with a code base that resembles a big ball of string. It can be tough to determine where a process starts, and where it ends. Therefore, in some cases, some remediation work needs to be done on the legacy side to create more service procedures. We will cover this aspect later in this chapter where we examine some of the pros and cons of SOA enablement.
In the following figure, we see that the business layer is abstracted and extended. So, we wrap the programs with legacy adapters to expose those programs as business services.
- Data Layer: In this instance, a SOA service or call can be made to a legacy data store or file system. This enables users to use native data calls, yet access relational or nonrelational data stores. With data integration, enterprises can support fully-transactional, bidirectional, andSQL-based access to any data store on the mainframe. This can also include change of data capture to facilitate data warehousing, integration, and reporting.