Succeeding With SOA Through Patterns - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Software // Information Management
12:16 PM

Succeeding With SOA Through Patterns

To design reusable services, focus on industry-proven patterns and practices to provide the best solution based on service-oriented architecture and the Web services framework.

There's little doubt that component reuse and increased flexibility are major objectives flowing out of the popularity of service-oriented architecture (SOA). Companies of all kinds and sizes are focused on reducing costs as well as business risk; they're improving the delivery and management of customer service and support; and they're tightening business/IT alignment through SOA-based solutions. Such success has not only confirmed the growing ease of building, deploying, and consuming Web services, but has also revealed one of the most fundamental SOA success factors: that is, that software reusability and flexibility don't arrive "automatically" with the new technology. In other words, using Web services alone doesn't guarantee reusability and flexibility.

Indeed, as more organizations build, deploy, and orchestrate business services using Web services, it has become apparent that you need careful and comprehensive application design to ensure delivery on the promises. What are the most significant factors to ensure reusability and extensibility of services?

Critical Success Factors

The first factor is proper verification of reusability potential across business domains. The goal should be to stay away from developing services based on the functional requirements for one project, without conducting accurate cross-domain analysis. Never assume that if even if developers correctly employ service interfaces and XML standards that services will be effectively reused by other projects.

Second, pay very close attention to service structuring. Too often, services aren't easily reusable in other projects because their structure (composition of components and their relationships) tends to be overly dependent on a particular realization of Web services interfaces. Dependencies among components within a service make the service less usable in other contexts. Moreover, when new functional requirements appear, it's difficult to extend the existing interface or isolate the changes. Also, new interfaces must be put in place, especially when the service control logic is buried in the code that does Web services processing.

The third factor is scalability. A frequent reason why you can't achieve reusability is poor scalability of deployed services. If component responsibilities within a service aren't optimized among distributed processing elements, services won't scale to high-volume levels in a cost-effective fashion.

Patterns to the Rescue

Since the seminal book Design Patterns (by Gamma, Helms, Johnson, and Vlissides, often called the "Gang of Four") was published in 1995, patterns have become a widely accepted form of stimulating software reuse. However, the impact is often limited by patterns' use as merely reference tools that give guidance for handling particular design problems. They should be considered a critical constituent of the architectural requirements for SOA, serving as a starting point in influencing decisions about organizing and structuring business services.

In this article, I'll discuss identification and use of two architectural patterns important to SOA: Layering/Tiering and Mediator. I've picked these two from among many others that are important, including Message Exchange Pattern (MEP), Java 2 Enterprise Edition (J2EE) core patterns (Business Delegate, Facade, Web Broker, others), and so on, because of their direct association with the issue of service structuring.

While you can find many good articles about SOA — and I'll be assuming in this article a general familiarity — little published information exists about how to identify key elements relevant to architectural structure. The chief issue is how to properly construct a high-quality, large-scale application by separating end-to-end processing into service-oriented n tiers. How do you implement each tier in a layered manner to increase architectural flexibility and reduce management and support burden? How do you properly leverage standard components where the module functions are oriented toward business services, and in light of emerging Web services technologies? The truth is that even if we were able to precisely identify "serviceable" business functions and have all the necessary application and middleware tooling, we'd still have no answer to the main question: How do we arrange application functionality or responsibility among distributed processing elements to maximize quality features when using Web services?

Single Service Layer: Not Enough

Figure 1: The service layer. (Adapted from Patterns of Enterprise Application Architecture. See Resources.)

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
1 of 3
Comment  | 
Print  | 
More Insights
InformationWeek Is Getting an Upgrade!

Find out more about our plans to improve the look, functionality, and performance of the InformationWeek site in the coming months.

Remote Work Tops SF, NYC for Most High-Paying Job Openings
Jessica Davis, Senior Editor, Enterprise Apps,  7/20/2021
Blockchain Gets Real Across Industries
Lisa Morgan, Freelance Writer,  7/22/2021
Seeking a Competitive Edge vs. Chasing Savings in the Cloud
Joao-Pierre S. Ruth, Senior Writer,  7/19/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
Monitoring Critical Cloud Workloads Report
In this report, our experts will discuss how to advance your ability to monitor critical workloads as they move about the various cloud platforms in your company.
Flash Poll