Exclusive Focus on Web Services May Blur SOA Vision

by Robert Morris
February 1, 2006

** Read this article online at http://www.mainframezone.com/applications-and-databases/exclusive-focus-on-web-services-may-blur-soa-vision


Mainframe systems have been the backbone of most enterprises for decades. Companies are now looking to Service-Oriented Architecture (SOA) to enable consistent reuse of applications and data without requiring the consumers of those resources to understand the mainframe. Unfortunately, the focus has been primarily on the mechanics of Web Services (e.g., SOAP, WSDL, XML, HTTP), and not on identifying and meeting the real requirements to deliver SOA benefits.

There’s no shortage of vendors willing to further confuse the issue by offering simplistic solutions to delivering mainframe Web Services, and claiming this is synonymous with delivering SOA. This approach should come with a warning label: “Web Service enclosed. All assembly required.” It’s like delivering a load of lumber to a prospective home-builder. Oh, sure, everything you need to frame the house is there—except a blueprint and a basic plan for how all the pieces fit together. Once you move past the high-level marketing messages—“ Instant house—just add nails!”, you start to realize that delivering mainframe SOA is much more than just delivering mainframe components dressed up as Web Services.

It requires:

The assembly of such right-sized services into a standardized, enterprisewide framework for the effective use of an entire company’s information and systems ensures the realization of a true SOA—all of which is why an exclusive focus on Web Services is shortsighted. So, how can organizations cut through the hype and get to a clear, deliverable SOA vision? The following three guidelines may be helpful.

 

1. Think “business services”: There’s a common misconception today that Web Services are necessarily required for—or even synonymous with—implementing an SOA. But talking “Web Services” instead of “business services” really misses the point. Web Services are likely to be a part of an SOA, but only as one of several technology options for standardizing access to services across the enterprise. The business services that comprise an SOA perform a more complex role than simply enabling the invocation of a function in a standard way. Besides being functions that are readily recognizable and understandable, they typically contain multi-step, multi-operation functionality, orchestrated within the service, with transparent communications and data transformation. Critical to successful SOA is the ability to understand and deliver such business services at the optimal level of granularity to facilitate reuse and to insulate the user from downstream maintenance. Otherwise, everything developed in support of the SOA simply becomes an elementary building block that will have to be assembled into a usable structure elsewhere, with all the attendant development, testing, and maintenance ramifications that implies.

So, how do you identify and scope a business service that will be the right kind of building block for your SOA? Start with the requirement that it be a recognizable business function. There’s a tendency here to start at too low a level—the level, not coincidentally, where the developers of the service are likely most comfortable. Instead, start your service definition at the endpoint— the employment of the completed service by the user. Consider, for example, the Customer Service Representative (CSR) who performs the job function “Get Customer Information.” This is just one step in the process of signing up a customer for a new service or product, but it’s a discrete job function within the process that the CSR will recognize and know how to use.

While the user sees a discrete, recognizable business task, under the hood, “Get Customer Information” is a multi-function, multi-operation service that’s a further indication you’re approaching the right level of granularity. It’s comprised of functions such as “Get Customer History,” “Get Customer Credit Rating,” “Identify Customer Pricing Level,” etc. Each function may invoke multiple operations, such as interacting with an outside credit bureau, then performing specific operations on the data returned in combination with the customer’s internal purchasing and payment history, in order to assign an appropriate pricing level.

Meanwhile, all this is transparent to the user. Further, use of the service itself is insulated from downstream changes to its underlying components. For example, if the company switches credit bureaus, the necessary changes can be made within the service without affecting the way it’s invoked by the CSR’s customer upgrade application. This combination of granularity and transparency ensures the highest level of service reuse, fulfilling the ultimate goal of the SOA.

The Web-Services-as-SOA approach would serve up each of the functions underlying the business service as a building block, which would then have to be assembled and managed by the service consumer. This do-it-yourself approach would include orchestrating the interactions between the various Web Services and the necessary data transformations, as well as the application inputs and outputs.

Further, when any of the underlying components change, the Web Services consumers would have to be alerted as to how and what to change in relation to their specific uses of the services. With a backto- the-drawing board reaction every time there’s a component change, the benefit—and therefore the likelihood— of reuse is lost, as is much of the advantage of implementing SOA.

 

2. Use Mainframe resources to deliver mainframe SOA: The key to driving reuse is transparency. Just as it’s crucial to the effective definition and delivery of services, transparency should also guide companies in defining the optimal mix of technologies that comprise the SOA. The opportunity to lower costs through reuse and leveraged maintenance is a key driver in SOA adoption. This provides good reason for companies to embrace the mainframe in their SOA strategies; it offers the opportunity to maximize the return on significant long-term mainframe investments. Moreover, the performance, security and scalability of mainframe functionality and data minimize the risk associated with implementing new SOA initiatives.

The mainframe is an ideal candidate for SOA participation. But an exclusive Web Services focus that results in a point-to-point delivery of unassembled building blocks puts far too much of a burden on the rest of the organization to try to understand what a company’s mainframe developers already know about the mainframe’s proven applications and data. Accordingly, companies may shy away from actively incorporating valuable mainframe resources, fearing that the knowledge required for SOA implementation and the knowledge required to create business services from mainframe applications and technologies can’t be bridged within the organization. So they set their Web Service developers to reinventing decades of core functionality, or borrowing pieces from distributed systems with inherent limitations in security, scalability and performance. They leave their MVP on the bench.

With the right tools, mainframe developers can be relied on to assemble the right-sized, multi-step, multi-operation business services. Instead of abandoning the mainframe, along with its proven functionality, for lack of service development skills within the community of mainframe expertise, companies should look for quick and effective ways to bring their mainframe developers up to speed on service development. Using just such tools, one of the nation’s largest mutual company insurers of property and liability insurance recently completed an SOA initiative that exceeded all expectations in development, testing and implementation.

This was due largely to their use of mainframe developers—subject-matter experts in mainframe functionality and technologies—to create mainframe-based business services for the SOA. The lead system architect taught the developers everything they needed to know about building SOA business services by using the development tool itself to model a service in a single realtime training exercise that took less than half a day.

Such a demonstration can be key to bridging the SOA and mainframe knowledge bases. It would have taken many months to effect an equivalent exchange of the in-depth knowledge of mainframe technologies, functionality and data sources represented by this audience to a non-mainframe audience whose expertise resides in Web Service development. Even if such an exchange could be accomplished, it would have significantly delayed the initiation of mainframe services development in the process. Ultimately, it would be misapplying critical skillsets. It’s like having a team of experienced framers sit on the sidelines because they’ve always worked with hammers, and you have a bunch of nail-gun technicians available. It’s far easier—and a smarter use of resources— to teach the old-hand framers to use the nail gun than to teach the technicians about framing.

Once the mainframe developers understand how the services they’re developing will fit and function within the SOA—assisted by tools that can readily demonstrate and model the process— they can use their existing mainframe expertise to quickly develop the complex services that make an SOA successful. These developers are uniquely equipped to galvanize SOA initiatives with proven mainframe functionality because they’re not limited in their understanding of how the mainframe components work together. This translates into faster time-to-market with greater agility—key benefits of SOA— and is a far more practical approach than attempting to transfer decades of mainframe experience and knowledge to non-mainframe Web Service developers, whose field of vision extends only to the mechanics of delivering point-to-point components.

 

3. Learn about the SOA ecosystem: Another area often overlooked in the Web Services hype is the need for a broader, integrated SOA environment. As we have seen, it’s not enough just to deliver the disconnected building blocks, thereby pushing the actual assembly of the SOA downstream. But by the same token, even the more complex, right-sized business services that empower the SOA ultimately need to be incorporated into a comprehensive implementation environment to constitute a cohesive architecture. It’s this overall environment that we refer to as the SOA “ecosystem.” SOA incorporates many moving pieces and parts, all working together to accomplish in a distributed environment the same levels of reliability, robustness, scalability, security, integrity and manageability that already exist in the mainframe arena. For the SOA to be successful in these areas, the ecosystem requires tested, tight integration among multiple IT platforms and services. Figure 1, which is from Steve Craggs, vice chairman of the Integration Consortium, illustrates the various layers and functional interactions that constitute the SOA ecosystem.

Special consideration should be given to the registry, management and security of SOA services at the outset, to ensure the services you create can be located, managed, and governed. The registry, for example, ensures services can be located, understood, and effectively utilized. So, it’s critical that mainframe- based services are added to the registry so service consumers can find and apply the right services to perform specific tasks. The service management layer is in charge of monitoring the execution of the services, ensuring that the right version of the service is employed, and that performance levels are acceptable. Security services are especially crucial in the SOA ecosystem, as functionality and data from previously “closed” systems such as the mainframe, are opened up to the distributed enterprise, which likely includes access even by external agents such as business partners and customers. It is important for SOA security to incorporate and take advantage of existing, platform-specific security features, such as RACF in the mainframe world, in order to provide the end-to-end security required in this distributed access environment. The SOA ecosystem must be well-understood and tightly integrated for all this to work together.

In a true SOA implementation—that is, a functioning, integrated business architecture, not just a loose collection of Web Services—it’s especially critical that the tools used to develop and deploy mainframe-based business services be well-integrated into the broader SOA ecosystem. This is due to the multistep, multi-operation nature of these services, and to the fact the ecosystem run-time is largely blind to the internal workings of the mainframe service.

To drive the components that comprise a multi-step service, the run-time provided by the mainframe service development tool itself should implement the execution path, providing all the necessary orchestration. While the SOA ecosystem will have the overall view, it will require visibility to the execution status of the specific mainframe components in order to provide the necessary security, and perform its service management and monitoring tasks. This visibility will result only from conscientious design of mainframe-based business services specifically for effective integration into the SOA ecosystem.

Stopping the design and development process at the Web Services delivery threshold, without learning about and planning for integration into the broader SOA ecosystem, is shortsightedness and will lead to SOA initiatives that fail to deliver the full potential of the architecture.

 

Sharpen Your SOA Vision

Companies can develop a clear, attainable vision for SOA implementations that fully leverage enterprise resources by looking beyond the Web Services hype. Key to this vision is a broader focus on identifying and delivering multi-step, multi-operation business services at the optimal level of granularity to ensure reuse and maintainability. Don’t get stuck at the level of mechanics and end up delivering a pile of building blocks, expecting the users downstream to figure out how to turn them into a functioning, efficient business framework.

Use all your resources to maximize the value of your SOA. Don’t shy away from using mainframe resources, both platform and personnel, to deliver powerful, proven mainframe functionality and data to the SOA. You can bridge the knowledge gap between mainframe developers and service developers, if you build your bridge over the “path of least resistance.” Instead of trying to turn service developers into mainframe experts, equip your mainframe experts with the right service development tools; tools they can use to quickly understand and deliver the robust, right-sized mainframe business services that will ensure SOA success.

Finally, become familiar with the SOA ecosystem from the beginning, carefully considering the requirements for service registry, management, and security to ensure your services will participate efficiently in the overall SOA. Go beyond delivering point-to-point Web Services to creating services that are designed and developed to be fully integrated participants in an enterprise architecture. Make sure your services contain the right functional components, and that the orchestration of that functionality within the service can be secured, monitored and managed by the components of the broader ecosystem. It’s operating together only in the context of this ecosystem that any collection of business services ultimately constitutes a fully functioning, beneficial SOA.

This article had no comments at the time of this printout.