SOA: Refactoring Mainframe Applications into Dynamic Web Applications, Part 1
By refactoring your mainframe applications into Web services you separate presentation from logic, and gain the ability to reuse mainframe data in Web applications. This two-part article describes the complete process.
by Jeff Hanson
Mar 11, 2005
Page 1 of 5
large number of developers (and managers) have heard of service-oriented architecture (SOA) and are familiar with the idea in principle, but have no idea about how to go about applying it to a particular system. This article begins a two-part series discussing how to refactor mainframe routines using service-oriented techniques into deployable services and make the framework available via the Web.
First, you need to understand some fundamental concepts surrounding SOA.
You should follow several SOA principles to gain the benefits of heterogeneous message handling, service reuse, etc. Here's a description of the main SOA principles:
Stateless InteractionsServices should be independent, self-contained modules, which do not store state from one request to another. In addition, services should not depend on the context or state of other services. You should define any state dependencies using business processes and data models rather than context objects or session keys.
Coarse-Grained InterfacesSOA optimization relies on services being constructed and exposed with coarse-grained interfaces. While each service may be implemented as an abstraction of a group of finer-grained objects, the objects themselves should be hidden from public access. You implement each service by grouping objects, components, and fine-grained services, and exposing them as a single unit using a service façade.
Loose CouplingsCoupling generally refers to the act of joining two things together, such as the links in a chain. In software engineering, coupling typically refers to the degree to which software components/modules depend upon each other. The degree to which components are linked defines whether they operate in a tightly coupled relationship or in a loosely coupled relationship. Service-oriented architecture (SOA) guidelines recommend that you construct services with loose coupling in mind. Loosely coupled components locate and communicate with each other dynamically at runtime as opposed to a static compile-time bindingoften referred to as late binding. This lets you deploy your applications as desired, making deployment decisions at deployment-time, rather than design-time.
Service Discovery and RegistrationServices should be registered with some form of public or private registry, such as a database, a directory service, a UDDI registry, or an XML file. After registration, components that want to call the service first use the registry to locate the service and then call the service.
Location TransparencyLocation transparency deals with the ability to access information objects without advance knowledge of their location. To achieve this, you specify service locations in configuration mediums such as UDDI registries. In addition, service calls should be targeted at common location endpoints such as URLs and URIs.
Protocol IndependenceSOA depends on a minimum amount of interdependencies between services. This loose-coupling must propagate all the way to the protocol layer of the architecture. The design of the communication infrastructure used within an SOA should be independent the underlying protocol layer. Some well-known implementations for protocol independence are:
Business DelegatesA Business Delegate hides underlying implementation details of a business service, such as lookup and access details.
Remote Proxies or SurrogatesA Remote Proxy acts as a stand-in for objects that exist in a different tier.
Figure 1. The Service-oriented Framework: Each tier shown in the diagram supports different functionality within the overall framework.
AdaptersAn Adapter provides transparent access to disparate objects or services by converting requests and possibly responses from one interaction interface to another.
BrokersA Broker decouples business tier objects from objects and services in other tiers.
FactoriesA Factory instantiates objects at runtime based on dynamic configurations. Factories often instantiate objects designed around the Strategy pattern or Bridge pattern.
Building the Framework from the Mainframe Out
For this article, the application framework follows a four-tier design, including a client tier, an application tier, a business tier, and an integration tier. Each tier serves to support different functionality within the overall framework, as shown in Figure 1.