Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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.


advertisement


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.

Introducing 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 Interactions—Services 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 Interfaces—SOA 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 Couplings—Coupling 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 binding—often 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 Registration—Services 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 Transparency—Location 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 Independence—SOA 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 Delegates—A Business Delegate hides underlying implementation details of a business service, such as lookup and access details.
    • Remote Proxies or Surrogates—A 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.
    • Adapters—An Adapter provides transparent access to disparate objects or services by converting requests and possibly responses from one interaction interface to another.
    • Brokers—A Broker decouples business tier objects from objects and services in other tiers.
    • Factories—A 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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap