Login | Register   
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 : Page 3

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
The Business Tier
 
Figure 4. Service Implementation Relationships: The figure illustrates the relationships between a typical service, its embedded components, and resource adapters.
The business tier defines objects, components, and services that encapsulate business logic for a given enterprise. You expose this business logic publicly as services to take advantage of SOA's benefits. With a system of services defined, an enterprise can reuse and re-orchestrate the services to form other services, processes, and applications.

The next section illustrates the implementation of a simple service that can act as a boilerplate for more complex services. The Service Implementation
Remember, each service should expose a coarse-grained instance of business logic for a given enterprise. Typically, you'd abstract and aggregate existing objects and components to form each service. You can build services that interact with legacy systems around components that interact with resource adapters, or the service code itself can interact with the resource adapter.

Figure 4 illustrates the relationships between a typical service, its embedded components, and resource adapters. For this article series, the goal is to refactor an application that tracks users and user accounts from a simple mainframe green-screen terminal program, as illustrated in Figure 5, to a multi-tiered, Web-enabled framework.



 
Figure 5. Original Green Screen System: The figure shows the original mainframe application running in terminal mode.
As you can see from Figure 5, the application stores user account information. The UserAccountService class in Listing 1 defines a service that returns a list of user-account names. The service uses the J2EE Connector Architecture API to interact with a fictional EIS system. The Service Locator
Locating a location-transparent service can prove to be a complex process, but you can use the Service Locator pattern to hide all location-centric details. A service locator implementation is typically a specific kind of service that interacts with some form of service registry to provide location-transparent service lookup.

The ServiceLocator class shown in Listing 2 illustrates a service locator which uses fully-qualified class names to construct services. This form of lookup is sometimes conceptually referred to as intra-VM or classpath lookup. More robust implementations would abstract directory service access, UDDI registry access, etc.



Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap