Jul 8 ’08
Do’s and Don’ts of Moving Legacy Applications to SOA
When moving existing legacy applications (or newly developed server applications) to a Service- Oriented Architecture (SOA), you must consider the SOA solution’s overall objectives and problems that must be addressed.
An SOA solution must help a business quickly respond to changes in the business environment and lower development costs through reuse of assets. Without this business agility, there’s much less reason to move to SOA. An SOA solution should make it possible to enhance an existing IT infrastructure, making it able to flexibly and quickly adapt, without disrupting current operations. The creation and publishing of services and message mitigation via Enterprise Service Buses (ESBs) provide this flexibility.
Building a Service
How well individual services are specified and realized (granularity) significantly impacts aspects of IT flexibility and business agility. The goal here is to provide and adhere to guidelines for specifying and realizing services that enable the SOA in your enterprise. A major emphasis is on decoupling service consumers from service providers. An underlying concept of decoupling is that changes to the service provider shouldn’t necessitate any changes to the service consumer.
To realize SOA objectives, the task of creating and modifying processes must be simplified and adhered to. Some problems process implementers face are:
• Selecting appropriate service operations (granularity)
• Arranging to invoke the services with correct parameters such as Web Services Description Language (WSDL)
• Handling various possible responses, including error responses.
The quality of service design can significantly affect the ease of service integration. Significant impact on orchestrating a business process occurs based on design decisions such as:
• The names and number of services
• Operations and parameters
• The quality of documentation
• The degree of interdependence between service operations.
Moving a legacy application to SOA requires addressing these issues.
The granularity of a service is defined in terms of the number of service operations it should contain. An operation causes some business function, support function, or transaction to occur.
Granularity can be rated on a sliding scale from “fine-grained” to “coarsegrained.” A coarse-grained service contains multiple operations that perform pieces of complex business functions. A fine-grained service is a single operation that carries out the entire function. Each type of granularity may or may not be appropriate as a service in your organization. As with everything else in the world of IT, it depends.
How do you decide what constitutes a service?
There are at least five factors to consider when designing services:
• Number and type of operations
• Cohesiveness of operations
• Completeness of operations
• Data integrity and validity before, during, and after the service
• Reusability of the proposed service.
There’s no hard and fast rule for the number of operations in a service. The service needs to perform the number of operations required to satisfy the service requester—no more and no less.
For a current consumer, it’s easy to create the service based on that consumer’s particular and specific requirements. But, remember, we’re trying to make the service reusable for potential new consumers. Would the proposed service carry too much baggage in terms of functions for a new consumer? If so, what functions might be overkill?
A cohesive set of operations belongs together in one service because they provide a set of related functions. Think of the service from the service consumer’s perspective when assessing cohesion. By considering the consumer’s perspective and addressing the consumer’s key use cases, you make the function of the service your focus.
A service is complete if it provides every needed operation for the targeted consumer’s key use cases. These are a sequence of events, performed through a system that yields an observable result of value for a particular consumer. The “80/20 rule” applies here since 80 percent of the consumer’s usage is handled by 20 percent of the system functions. That 20 percent of the functions are what would be defined as a key use case and it’s an excellent starting point for cohesive, complete service building. Take the other “nice to have” functions and develop additional services. A developer could then take the key use service and compose it with one or more of the nice-to-have services to accomplish some new consumer’s requirements. For a good description of use cases and how to discover them, read Gary Ham’s article, “Four Roads to Use Case Discovery,” circa 1998.
Use the noun-verb naming convention for services and operations to help focus on the functional cohesiveness of the service interface. Simply ask: Is the verb something that the noun does? The service should be expressed as a noun and the operations named using verbs in phrases with clear business meaning. The business intention of the service should be clear, not just the outcome. So, rather than maybe “update customer master record,” you might specify, “enable Internet statements.”
If granularity is too coarse, and you group together large numbers of operations in a single service, then this tends to increase the number of consumers for the service. So, if you perform maintenance or enhancements to that service, you immediately impact many consumers.
A service should usually be the unit of testing and release.
So why else is the granularity of the service important? The most important consideration is the follow-on administration of the services (see Figure 1). You must publish (register) your service to a registry that will let consumers:
• Find the service
• Learn how to connect or bind the service (via the contract)
• Execute the service (bind and invoke).
When an organization goes the route of fine-grained services, the administration becomes difficult because thousands of services probably must be registered. The use of a plain Universal Description, Discovery and Integration (UDDI) or Lightweight Directory Access Protocol (LDAP) type of registry is insufficient to deal with proper categorizing and administering the volume of services. A consumer might find it a challenge to successfully find the service. You must look at true SOA registries and repositories such as the IBM WebSphere Registry and Repository, the BEA AquaLogic Registry Repository, or the SOA Software SOA Registry or Repository. There are hundreds of vendors selling such products. Some are functionally rich and expensive; some are functionally poor and cheap.
The upside of fine-grained services is that a change to a service usually impacts only a small consumer community.
Even the most coarse-grained services will add up over time. So the registry or repository is still a required item for proper governance of the SOA environment. You can create an initial pilot SOA project without an extensive registry or repository; a simple LDAP registry will do nicely for a pilot.
Services Equal Messages
Stop to consider that today’s SOA implementations heavily rely on Web services. Web services equate to messages across some transport mechanism (ESB, WAN, LAN, etc.).
Consider the challenge of moving to SOA a COBOL legacy application that’s been used for years and patched as each new merger or acquisition occurred—so much that the code is now pure spaghetti and almost impossible to decompose. To migrate this, you could rewrite the spaghetti into a new set of programs that each encapsulates a specific business function using some modern language. You could then assign each module as a service. This is a very finegrained approach and would cause administrative issues and be costly.
A better approach might be a façade service that, based on the consumers’ contracts, goes down one logic path or another in a single application object. This would leave the spaghetti pretty much alone until such time as it makes sense to re-engineer the application. This same technique also would be used when a single procedure in a service needs to be modified for a new consumer without impacting the old consumer.
Consider Figure 2, which comes from the NetObjectives Repository. Here, we’ve developed a Concierge Service that actually connects to one of three unique program paths, methods, or modules behind the scene.
When large procedural systems of extreme complexity or spaghetti code are required, we can create a “gateway routine” as a sort of Application Program Interface (API) that allows aggregation of many different parts of the system into a single logical service. This “gateway” routine makes the system easier to use, and is essentially the precursor to a façade in an object-oriented system. It isn’t strictly an analog; it’s an early version of the pattern.
In SOA view, the system would look more like Figure 3, where some services still link or call each other without Web services. This would usually be used for higher-performance applications.
The same direct link/call techniques should always be considered before making two interdependent functions separate services. The unnecessary overhead of Web services messages, XML translations, and message and transport layer security should be avoided unless there’s a compelling reason to make existing assets into a service.
One of the premises of SOA is that services should, when possible, be stateless. The instance of the service shouldn’t care what has occurred before its existence. In many legacy applications, state information was maintained between functions because of data integrity commit and back-out requirements.
Sometimes, it’s impossible to avoid the requirement of maintaining state information, so you might either rewrite part of the application to store state information in the Web services messages or use a façade service. Figure 3 shows “Existing 1” going directly to “Existing 7,” and both 1 and 7 using Existing 5. In this case, Existing 1 may start a database operation that’s finally committed in Existing 7.
Moving legacy applications to an SOA can fairly easily and quickly occur today with existing tools. The worst part is determining what makes an SOA service. This article has tried to provide concepts, ideas, and practical advice on how to determine your legacy application’s SOA services. Z