• How can I leverage and append the proven safeguards already in place?

• When I start distributing access, how can I maintain control, pass audit, and ensure security remains adequate?

• What level of risk is appropriate to get the quality of service I need?

• How will I know if I’ve broken or invalidated the security that’s in place?

• Will I be able to limit levels of visibility once application x is talking to application y?

• Who will be able to gain access and what systems will ensure proper access?

Forms of SOA enablement, specifically front-ending legacy applications with a “wrappered” service tier, can help you address these concerns. This article doesn’t focus on service-wrapping technologies, but provides guidelines on reconciling the use of services against your own IT environment with the right application-integration solution. We’ll examine several ways to safely reuse mainframe application data and logic in an SOA and cover best practices for ensuring proper host application involvement.

SOA vs. the Mainframe Application

The power of the pure SOA approach lies in its flexibility through service composition and reuse. Services in a formal SOA, by nature, don’t know how they’ll be used because their use isn’t yet determined. Developers employ them as needed, in different ways for different purposes. This ambiguity is by design.

To provide oversight to critical resources, an SOA counts on forms of governance to track services and ensure proper usage. The oversight is external to the services and beyond the control of the services themselves. It’s a trust relationship in the sense that the services “trust” some part of the infrastructure is protecting them.

6 Pages