By Len Erlikh, CTO, Relativity Technologies
COMMENTARY--Web Services are the latest in a series of industry-wide initiatives to connect and integrate extended enterprise applications. Despite having few deployments to date, Web Services have generated a wave of industry-wide excitement and bring the promise of delivering the next revolution in systems interoperability.
Much has been written about creation of new applications within a Web Services framework, and the workings of this technology.
The reality, however, is that the vast majority of today's IT systems still run on legacy platforms and are simply not architected to take advantage of new technologies. These systems have been built at a high cost over many years, and the knowledge of the business is usually locked within these undocumented systems. There is no simple way to replace them. Legacy systems are here to stay and no extended enterprise solution is complete without a viable approach to embracing the legacy platform into its composite applications.
Web Services place a number of very specific architectural requirements on the way the underlying business function needs to be implemented. These architectural requirements are based on the notion of:
* Componentized Assets
* Dynamic Binding
* Composite Event Definition
* Standard Deployment Environments
Legacy systems usually fail to address any of these architectural requirements. They are monolithic in their very nature and were built using rigid, hard-wired business process flows with no notion of composite event definition. It is not usually possible to integrate these into a Web Services framework without intrusive modification.
Legacy systems need to be reshaped and re-architected. The complexity and the magnitude of this task requires a considerable degree of technological innovation and automation using technologies such as RescueWare from Relativity Technologies.
Legacy Web Services Identification and Encapsulation
A typical legacy system is composed of hundreds or thousands of independent programs. These programs work together in a hard-wired cluster of business process flows. In order to refine the legacy system into Web Services it is important to segregate these programs into clearly identified collections that perform in-kind business functions. The top-down process of legacy system componentization begins by establishing logical subject areas of business functionality, and should be done by a subject-matter expert. Each business area should be examined for size and complexity. Large-size business areas should be refined into manageable number of programs that contains crisply defined target business functionality.
Creating Legacy Web Services APIs
At this point, the boundaries of the newly established Web Services are well defined but the system as a whole is still tightly coupled via program-to-program calls or common references to global persistent data. The modern approach to large-scale system de-coupling is to remove from the individual Web Services any direct knowledge of any other Web Services. This can be accomplished by breaking up program-to-program connectivity and replacing it with a SOAP-based interface that is coupled with one of the emerging EAI techniques such as hub-and-spokes, publish-and-subscribe, or business-process automation integration.
All of these techniques accomplish the same task of creating complex composite applications by pushing knowledge of the overall system integration into an independent broker entity. The UDDI repository and its WSDL-based definitions for individual Web Services support the dynamic nature of the newly created application. Another notable shift in paradigm here is a move from synchronous, single-threaded, call-based transfer of control to asynchronous message-based communications, which facilitate distributed concurrent processing.
Legacy Web Services need to publish clearly defined APIs to facilitate loosely coupled system integration and flexible workflows. An emerging technique of Knowledge Mining offers a number of business-rule extraction techniques that facilitate the process of identification and publishing of legacy Web Services APIs. In essence, Knowledge Mining decomposes mission-critical systems into a collection of object-based fine-grain components that can act as access points/APIs to larger Web Services.
Identification of Web Services APIs is based on the premise that every mission-critical program is composed of three distinct layers:
* Business Rules
* Process Flows
* Environmental Support
Business rules embody the fundamental business practices and policies of the enterprise. Examples of business rules include interest rate calculation algorithms, customer credit rating approval policies, and student graduation requirements. Business rules provide the business foundation of the underlying system. They are a very stable and technology-independent aspect of such systems.
Process flows tie the system's business rules into unified processing units. The flows are subject to greater change than the underlying business rules. When using an EAI engine, such process flows can be factored outside the application code.
Lastly, a significant portion of any system is dedicated to managing the physical aspects of the underlying operating environment. These tasks include screen, storage, and inter-process communications management. Environmental support is secondary to componentization.
Knowledge Mining of business rules from existing systems is at the core of identifying Web Services' APIs. Business rules are, in effect, the business Services of the system that are to be published as Web Services. Although legacy business rules are not object oriented by nature, they can provide for a high degree of reuse, modularity, and encapsulation of a specific business function, as well as a solid foundation for the individual Web Services.
Deploying and Publishing Legacy Web Services Using Industry Standards
Once identified and encapsulated, Web Services can remain on a mainframe in their existing language or be transformed into a new language like Java or Visual Basic using technologies such as RescueWare.
In either case, the resulting Web Services can be packaged for distributed accessibility using a combination of SOAP, WSDL, and UDDI. A combination of callable APIs, wrappers, and proxies can bridge the mainframe-resident components into the distributed Web Services framework.
The potential here is to turn lead into gold. Web Services provide the infrastructure for the interoperability of diverse applications, and true integration of the enterprise. Opening up the legacy infrastructure and transforming this into Web Services is the key to accelerating the improvement of industry business processes.
Len Erlikh is Chief Technology Officer of Relativity Technologies, a leading software and solutions company for legacy modernization. For more information on Relativity Technologies, please visit www.relativity.com.