Legacy Integration_ A Critical Part of SOA

Document Sample
Legacy Integration_ A Critical Part of SOA Powered By Docstoc
					      Legacy Integration: A Critical Part of SOA
by Ron Nunan
July/August 2006




Today’s enterprises are making substantial progress in moving enterprise
applications to a highly flexible distributed architecture. Commonly referred to as a
Service-Oriented Architecture (SOA), this movement leaves behind the silo or
monolithic approach to solving business requirements and has become a requirement
for staying competitive in a turbulent market.

SOA is now a fully accepted architectural approach that has re-defined the look of
new enterprise applications. Drivers for the SOA movement include the need to:

• Be responsive and flexible to continuously evolving business needs
• Overcome the challenges introduced from shorter technology lifecycles, which yield
incompatible, heterogeneous software systems as business applications outlive the
technologies with which they were created
• Address the pressure to extend business services to broader audiences.

The benefits associated with an SOA are complicated by the massive existing
inventory of older applications; most enterprises have an inventory of reliable and
functional applications that weren’t designed to participate in an SOA. The challenges
of accommodating these existing applications are twofold:

• Older applications built with a different generation of technology from those typical
of an SOA; many based on legacy or mainframe systems
• Application dependencies and the behavioral context the application assumes.

The legacy application challenge can be solved using any of several available
integration technologies. The application dependencies can’t be solved simply
through the use of integration technology. That problem will be solved only when the
implementation of an integration technology correctly accounts for the behavioral
requirements of the integrated applications. The key is in the implementation of the
integration effort. While getting the applications to a common technology is the first
step, the next step is assuring that the extended workflow of the finished solution
doesn’t break the legacy application.

SOA Integration

Enterprises for several years have invested in and built out SOA projects. This
includes pulling disparate information systems together through common
technologies and integration efforts. Legacy systems are often perceived as
roadblocks to implementing SOA because these systems don’t share the aspect of
common technology that’s fundamental to tying together the applications when SOAs
are built. To the typical SOA application developer, the legacy applications are just
an unknown black box of business functionality.

To get past this perceived roadblock, the legacy systems need to be represented in
SOA-understood technologies. This is an integration effort that’s most successfully
solved through service wrapping. An assumption of SOA is the use of granular
reusable services that can be made and re-made into composite applications as
required. Legacy applications can quickly and easily be wrapped, letting them be
seen from the broader enterprise as just another set of reusable components.
Specifically, this lets monolithic applications be seen and used as a set of small
reusable components that are granular slices of the original application.

This task is where modern legacy integration tools excel. Using SOA technology-
based integration, almost any user can service-enable functionality already available
from legacy applications for use in various SOA-based initiatives. Benefits include:

• Non-intrusive process: Legacy integration shouldn’t require application changes. An
SOA-based approach eliminates the need for architectural changes and reduces the
likelihood of downtime. It also enables integration of applications using various
methods: the user interface, application logic, and directly to the data.
• Lower risk: With legacy Web integration, the first project is often completed in a
matter of days, and further integration can occur iteratively, as experiences and ROI
from the first integration accrues. That way, enterprises can try out new
opportunities at a much lower risk than traditional methods allow.
• Time-to-market: Even complicated integration projects can be completed in weeks
rather than months or years. Businesses can gain competitive advantage by
leveraging the functionality trapped in existing applications faster than competitors
can.

Legacy Integration Tools

When evaluating legacy integration, organizations should investigate solutions that
can deal with strategic applications that convey functionality resident in mainframes
and other legacy systems, or business process exposed through Web interfaces and
homegrown Windows applications. The solution should support a wide range of
industry standards to ensure that solutions developed today work tomorrow. This is
critical, as an SOA isn’t a set of Web Services; it’s a set of services. How the services
are built, and with what technologies they’re built, depend on the desired business
outcome.

For legacy access, it’s best to not tie the integration to a specific technology. A tool
that supports the definition of a service as an abstract that can then be turned into
any appropriate technology, such as a Web Service, will have a longer life than any
tool that’s technologically specific.

When looking for a legacy integration solution, consider a solution that offers:

• A rapid approach for reusing legacy functionality abstract service creation
• The ability to expose created services as any type of component or technology (The
more abstract the service, the more reusable it will be over time.)
• A graphical, simple point-and-click process for abstracting required legacy
functionality in component form that doesn’t disrupt the underlying legacy
application
• Functionality that insulates developers from the intricacies of legacy technologies
• The ability to create clear layers of abstraction, producing solutions that don’t
require re-engineering existing applications to access the underlying functionality.
Dependencies

The issue of dependencies isn’t always an obvious one. This has everything to do
with the context of the involved applications’ business requirements and the
applications’ original architectural approach.

SOA isn’t about creating services; it’s about building distributed applications from
reliably reusable services. That’s why SOA has at its foundation a set of attributes
that need to be employed. If we look at a few of them, we can see a possible issue
with the use of legacy applications:

• Services are stand-alone with few dependencies
• Services should be loosely coupled
• Services are location-independent.

The goal of an SOA is to offer every function as a low-level or granular operation
within the service (see Figure 1). Services, in a proper SOA, are typically granular
enough to be devoid of any specific business context; having this level of granularity
lets the services be used and reused in larger combined or composite services. If a
base-level service were to be built to meet the needs of a specific business workflow,
then its reuse for other business needs would be curtailed.

For legacy applications, enabling technologies solve the issue of creating low-level
granular services. What they don’t solve is the dependency limitations on how they
can be used, including the activity of composing larger, coarser-grained services with
business context.

SOA With Legacy Applications

Many legacy applications were built with the assumption of strong control over
resources. This is easily seen when thinking about a transactional application. While
this type of application necessitates some technical detail, the result is best practices
that benefit the successful SOA.

Consider a legacy application that governs financial information, for example. To be
completely sound, the application must ensure activities at the business level happen
completely or not at all, regardless of how the application components are used. This
requires a high level of trust in the use of components.

For legacy applications, implementing discreet pieces of legacy software to perform
as a single unit of work is essential to many of the embedded businesses. The
common expression for this is “transactional control.”

Typical methods used for transactional integrity by legacy applications force the use
of locks on the underlying components—the pieces of the application that actually
perform the work. To guarantee a successful outcome and keep the application
performing up to expectations, these locks and the duration of the activities are
tightly controlled. Again, this is a common method employed in legacy application
design.

This practice typically centers on short-lived operations—processes where the result,
success or not, is quickly known. Unfortunately, this is at odds with a well-behaved
SOA, which prefers services loosely coupled without tight control.
 Developers often find that SOA transactional controls and specifications aren’t
designed to bring transactions into the Web Services world. While SOA technologies
let developers make many new changes to existing applications, they don’t remove
the basic legacy needs and requirements these applications depend on and need to
accommodate.

Using legacy components as lower-level operations or as services in an SOA puts the
burden of understanding the legacy application’s workflow on the SOA developer. It
alleviates the need to know legacy technologies, but not the legacy application. For
example, developers with SOA initiatives that use legacy assets need to remember
to:

• Focus on architecture rather than a technology. Envisioning everything that can be
done to a legacy application with SOA technologies isn’t the road to success.
• Understand the needs of the application. If the legacy application is mapped
directly into an SOA technology, the risk of not building in business context is high.
This curtails the basic SOA benefit of reuse. Conversely, a solid understanding of the
legacy application is important when designing the services to ensure their use won’t
harm the source legacy system. If this is the case, then a more tightly coupled, less
reusable implementation may be necessary.
• Collaborate across teams. Cross-departmental understanding, especially with the
legacy application architects or developers, is necessary. Politics and a lack of
common ground between legacy and SOA development groups is a real barrier to
realizing a successful SOA project. Legacy-based services should dictate
development understanding across team boundaries. Involved groups should span
legacy understanding and SOA skills.
• Account for legacy assets: To succeed with an SOA in most enterprises, legacy
assets need to be correctly accounted for. Doing that requires engaging resources
literate with the involved legacy applications and then leveraging the readily
available yet unique set of tools that create the needed services out of the legacy
assets.

Conclusion

By making legacy integration a critical part of the SOA infrastructure, companies can
share computing resources more efficiently across all organizational units and get the
most out of their SOA investment.

Whether driven by business needs, user requirements, or customers’ service
expectations, enterprises that have built their business on reliable legacy systems
realize their strongest competitive edge with SOA lies in their legacy assets—data
and business logic.

Organizations have discovered that by leveraging their existing legacy resources to
serve new SOA business requirements, they can achieve immediate ROI and gain a
competitive edge.

By adding legacy integration software to the SOA technology mix and planning,
companies can create new opportunities to innovate with fewer technological
constraints, maximizing legacy and SOA investments.

Service-oriented legacy integration software is the key to successful SOA adoption.
By leveraging legacy integration solutions with existing SOA integration and Web
Services technologies, companies can decentralize legacy resources, enable the
development of connected systems, services and composite applications, and place
legacy data and applications on equal footing with modern technologies.

About the Author

Ron Nunan
Email: Ron.Nunan@attachmate.com

Ron Nunan is a chief strategist with Attachmate and a strong proponent of SOA. He
seeks avenues to help customers address current integration needs while helping
build a foundation for future initiatives. Together, Attachmate host integration
solutions and SOA empower companies to embrace emerging technologies such as
SOA, speeding real-time business initiatives while helping reduce IT complexity and
cost.

				
DOCUMENT INFO