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.

Stateless?

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.

Conclusion

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  

5 Pages