Maximize Reuse of Services Within Your SOA
Leverage existing infrastructure, create appropriate organizational structures, and adopt collaborative development practices.
by Theo Beack

February 13, 2006

Service-oriented architecture (SOA) is one of today's hottest topics. No matter where you go, or which customers you engage, the same topic is foremost in their minds. People want to know how to use or build an SOA to (a) solve some of the most pressing business problems, (b) create more integrated business solutions, and (c) reduce the cost of building and maintaining existing IT infrastructure and applications.

Much has been written on the value of SOA and how it will help organizations meet all the aforementioned objectives. How to design and build a solid SOA is another common topic, and it appears that everyone has an opinion on what constitutes a "service." IT architects love to discuss the best approach for designing an SOA. Yet, it appears that relatively little has been written about one of the most important aspects of SOA: how to foster reuse of existing services.

In this article, I will explore one of the prime reasons we are using SOAs to solve the most crucial integration and business problems, namely the reuse of existing applications, business processes, and infrastructure. Many organizations struggle to reach wide adoption of services within their SOAs, despite creating them with reuse in mind. This article explores the ways in which practitioners of SOA can maximize the adoption and reuse of services by leveraging the existing infrastructure, creating appropriate organizational structures, and adopting collaborative development practices.

SOA Assumptions
When reading SOA-related articles or conversing about SOA, the majority of people often make the same basic assumptions:

• You don't need to rip and replace existing systems.
• SOA and the use of Web services standards help ease the pain of integration.
• SOA allows the reuse of existing applications (home-grown and packaged).

Everyone seems to agree that reuse is one of the prime reasons for SOA's widespread use and success. Few question what "reuse" really means, or how it can be achieved.

Before continuing, you should consider two sets of questions. First: What does reuse really mean in the context of SOA? Does reuse imply the reuse only of newly created Web services? Does it also include the reuse of existing applications? Does it include the reuse of existing programming and technology best practices, and/or software development guidelines?

Second: How does one achieve reuse? Many organizations that have embarked on the SOA path have realized that achieving true reuse is not as simple as creating Web services and making them available for use. Many different factors seem to wreak havoc on service use within an enterprise.

Understanding the nature of reuse within the context of SOA, and how one can generate the adoption of services, is an important step toward achieving one of the important promises of SOA.

What Is Reuse?
Reuse can take many different forms as described earlier, but my simple definition of the term is the ability of various people or service consumers to use the exact same service, component, procedure, guideline, or process repeatedly to fulfill a given task. From this definition it is clear that reusability extends beyond the mere reuse of Web services or existing applications (exposed as Web services). It also implies other focus areas and disciplines that are crucial to building a culture of collaboration—thereby providing the means to create a truly reusable approach based on the principles of SOA.

When engaged in planning and designing an SOA, establish a culture of reuse within your organization by focusing on these areas, which I call the "Services Adoption Framework" (see Figure 1):

• Best practices.
• Guidelines and policies.
• Architecture blueprints.
• Organizational structure.
• Communication.
• Services and metadata repository.

Reuse of services is often more complicated in practice than in theory. Many factors can stall reuse, such as lack of organizational support; lack of guidelines and best practices; interoperability; lack of standards; services discovery, and poor communication. Next, I'll address each of these issues in more detail.

The first factor that frequently stalls reuse is a lack of organizational support. It is important to have appropriate support from both developers and management when implementing an SOA. The biggest challenge is often a cultural challenge rather than a technical challenge.

Implementing an SOA implies change—sometimes a lot of change—and people deal with change in different ways. To some extent, most people are resistant to change, especially when they have not been included in a decision that directly impacts them, or when they do not agree with an approach or decision (even if they have been consulted in the decision-making process).

Firm support from all levels within the IT organization is necessary to implement an SOA successfully and reach appropriate levels of reuse. Management support is most crucial because managers drive the IT strategy, fund IT initiatives, and provide backing when important decisions have to be made.

IT architects, development managers, and developers play an important role as well. Without their solid architectural direction, some of the other issues discussed in this article have the potential to become major obstacles. Likewise, without the support and participation from the development teams, an SOA initiative is doomed. When the development teams are committed to the strategy and follow the established guidelines and best practices, you can be assured that your organization will be much nearer to achieving reuse of the SOA approach.

The second hurdle to reuse is the lack of guidelines and best practices. Many SOA implementations flounder without focus or amid conflicting agendas. By first establishing pragmatic best practices and programming guidelines, you can create a clear SOA discipline. Most programmers learn to code by example, so the most effective way of helping programmers adopt Web services and SOA is by providing them with practical examples and guidance on how to create and consume Web services. Simultaneously, you must steer programmers away from the most common mistakes and bad programming techniques, which can lead to all kinds of inefficiencies and interoperability issues.

Interoperability, the third reuse hurdle I'll address, is one of the main problem areas preventing consumers from easily interacting with service producers. Often a consumer can interact with a Web service that uses the Remote Procedure Call (RPC) binding style, yet it cannot interact with a similar Web service that exposes itself using a Document/Literal binding style. Other times a consumer is unable to deal with complex data types that are created by exposing a legacy application.

By establishing programming guidelines and best practices and following recognized architectural blueprints, developers can prevent these interoperability issues from occurring. Also, anticipating such issues allows architectural teams to put a framework in place that addresses these incompatibilities when they arise.

Fourth, a lack of standards can lead to competing approaches for creating, exposing, and consuming services. Web services are not mandatory when creating an SOA. Many developers prefer to use XML or XML RPC, or even a Representational State Transfer (REST) style of Web services.

Different standards can lead to many practical issues when implementing an SOA. It will serve an SOA team well to establish relevant standards and adhere to them. This can be enforced through the use of a services repository, which can perform a compliance test against the WS-I Basic Profile (for example) to ensure that all published services comply with relevant specifications.

A fifth reuse hurdle is services discovery. Many organizations have no effective means of determining which services exist and how to access them. This will remain a problem area until you have an approach to manage services and provide a central location to store metadata and artifacts related to the SOA services.

Finally, poor communication can hinder reuse. Does everyone within your organization know where to look for services? If not, how will they locate the services they need? How do you make changes to existing services, and even more importantly, who are your service consumers? If you don't know who your consumers are, how will you be able to notify them of the potential impact of changes?

How to Get Maximum Reuse
When implementing an SOA, you are faced with the question of where to begin. You might be tempted to start building Web services immediately, and many organizations take this route. This approach might work if the scope of your project is only to create a number of Web services. But when designing and implementing an SOA, diving right in is not the best approach.

The initial methods used to create, deploy, and consume Web services usually establish a pattern of behavior that might be difficult to change later. Establish practical guidelines and best practices first. Experience is the best teacher, and it is through trial and error that you can determine what works and what doesn't, or the best way of solving a particular problem. If you don't have the necessary resources or experience, it is worth the effort (and expense) to obtain help from someone with proven experience planning and building SOAs.

Next, define the architectural roadmap, or blueprints. Blueprints usually are extremely useful in guiding development teams because they address specific design areas within applications. Your blueprints might include any of these and more:

• Common security model.
• Service orchestration model.
• Metadata management.
• Process integration mode.
• Web services compliance model.

Too often, development teams have to reinvent the wheel to solve a particular problem. By solving problems once and documenting their solutions in architectural blueprints or best-practices guidelines, you achieve a certain level of reuse. Repeatability takes many different forms, and blueprints can have a positive effect on how services are created and used within the established SOA infrastructure.

Reuse Through a Services Design Approach
When creating services, it is important to start with a services design specification. Starting here allows you to identify which services will be needed, what their interfaces should look like, what the scope of each service will be, and the granularity of each service. Often, services are created without considering these aspects of the service. The extent to which you consider all aspects of a service has a direct impact on how useful it will be to potential service consumers.

By following a services design process, you can evaluate the requirements for different services and how they will be used. A thorough evaluation results in a balanced view of the different services for consumers' unique requirements. A good services design process yields a highly reusable set of services. An example service design specification should address the aspects of the service shown in Figure 2.

When taking the first steps toward an SOA, you usually start with the familiar. A large percentage of IT organizations have legacy systems that form the core of their mission-critical applications. This is usually the starting point when building an SOA.

Ask yourself how to reuse these systems or identify which parts to expose. First, determine which parts of a particular application will prove the most value when exposed as services. Next, ask what type of information is needed by other parts of the organization and what functionality would solve the most pressing request for information.

Then determine the different approaches you can follow to expose the identified functions as services. Generally, you can integrate with legacy systems in one of three ways: on the Session level, the Transaction level, or the Data level. By exposing these legacy applications as services through one of these approaches, you can reuse existing application functionality in new applications.

Session integration is the ability to intercept and interpret the screen information that is passed back and forth between a client and the server, such as z/OS, AS/400, Unix, and so on. The terminal session (or screen information) can be packaged using different protocols, such as 3270, vt100, and 5250. These protocols describe the data related to the user interface and how it should be interpreted and rendered by the receiving application (terminal emulator). With session integration, it is possible to intercept the terminal emulation protocol data and render it in nontraditional ways; for example, the 3270 session data can be rendered as XML or as a Web service. This can be done without the requirement to reengineer or modify the legacy application in any way.

Transaction integration refers to a style of integration in which existing legacy transactions, such as BATCH programs or online CICS transactions, can be accessed from distributed platforms. External applications should be able to call these transactions without having to know any of the implementation details. These legacy transactions need to be wrapped in such a way that they are callable as Web services without disrupting the original state of the application.

Data integration is the ability to provide a standard level of connectivity (typically ODBC or JDBC) to disparate data sources. This functionality is important for legacy databases that do not support SQL or provide ODBC connectivity natively. The ability to expose these data sources as Web services enables data to be accessed in new ways and for new purposes.

Role of Services Repository
Many organizations start their SOA initiatives by creating ad hoc Web services. The existence of these Web services is usually known only by select developers, and the information related to these Web services is usually shared in an informal way, such as e-mail. This approach usually works with a small number of Web services and consumers. Managing the artifacts related to the Web services (WSDLs, XML Schemas, XSLT) is not a pressing need, and usually an informal agreement exists about how to deal with upcoming changes in the service contracts.

However, this approach breaks down when adoption expands to dozens or hundreds of services in the organization. Suddenly the organization is faced with new problems:

• Where do you go to determine which services currently exist within the organization?
• How do you determine whether the service contract that you have located is the most recent version?
• How do you determine who are the consumers of a particular service?
• How do you determine the potential impact of a change to a services contract?
• How are new services documented and where do you publish a newly created service?

These considerations have a direct impact on the reusability of the existing services. A services repository can play a prominent role in determining the answer to these questions and the success of SOA projects. Organizations have found that in order to properly manage services within their SOA infrastructure, they must have a central services repository where all the services can be published and documented.

The services repository provides standardized interfaces, such as UDDI, through which service producers can publish their services. Repositories also allow service producers to document their services by providing additional metadata that help consumers find appropriate services through different classification and search mechanisms. Consumers can be assured that whenever they bind to a service, they will do so with the latest service contract. Likewise, service producers now have the ability to track how their services are used and by whom.

Implementation of a service repository greatly increases the communication between the service producer and consumers, as well as the development teams. It is the central mechanism from which the various development teams can obtain the latest information regarding a necessary service. Most IDEs today provide UDDI support or plug-ins that allow developers to browse the services repository without having to leave their IDE environment. This ease of use inspires "integration" between the various parties involved in the SOA.

This article has only begun the discussion of reuse within SOAs. Many of you likely have unique insights and different perspectives that would turn this topic into a lively debate on the merits of reuse, how to cultivate it, and what it really means. Feel free to e-mail me your thoughts.

Finally, planning is a crucial part of success. I have encountered several situations where organizations were highly successful in their usage and adoption of Web services, but failed to prepare for success—to such an extent that their success created unique problems that hindered further growth and maturity within their SOA implementations. Above all, it is the proper planning, disciplined approach, and determined execution that lead to a successful and reusable SOA implementation.

About the Author
Theo Beack is Chief SOA Architect at Software AG North America. For the past nine years, Theo has focused almost exclusively on integration technologies and has extended his skills to become an expert in service-oriented architecture, XML integration, Web services, enterprise information integration, and semantic integration.