In-Depth
Book Excerpt: Best practices for building Service-Oriented Architectures
 This article is excerpted from Chapter 13 of "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services" by Thomas Erl, ISBN 0-131-42898-5, $39.99. This excerpt is printed with permission from the author and Prentice Hall/Pearson PTR.
Many organizations underestimate the magnitude of adopting Service-Oriented Architecture (SOA). Building solutions that incorporate Web services and service-oriented design principles from the ground up requires a significant departure from the manner in which traditional distributed apps have been planned, designed, implemented, and maintained.
|
SOA can challenge an organization on many levels. Service-oriented concepts, for example, demand a new mindset for modeling business process automation. Not only do they introduce new terms and models, they intrinsically promote interoperability and process integration. Additionally, integrating the many underlying technology layers that constitute a contemporary SOA can prove to be a daunting task. The required research, skill set upgrades, development environments, and the inevitable shift in how applications are designed all impact IT staff, processes and, of course, budgets.
While SOA undisputedly provides opportunities for engineering a highly interoperable enterprise, it comes with the non-negotiable requirement that an organization commit to and invest in the "service-oriented way."
This article contains a handpicked collection of best practices from "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services," a book I recently completed for Prentice Hall/Pearson PTR. This list is by no means complete; it simply addresses some of the more common issues firms face as they tackle the service-oriented paradigm.
I would encourage you to use these best practices (as well as the additional ones provided in the book) in two ways -- first, as a heads up as to what you are getting yourself into when you decide to take that step into the world of SOA. The practical considerations discussed in many of these best practices may help you to determine the extent to which you want to integrate and standardize on SOA and Web services.
Second, if you are at a point where you are looking for standards and best practices to incorporate into your organization, view these as a reference point. Instead of simply publishing them on your local intranet, take the time to understand how they might impact your current environment, and how aligned they are with your strategic goals. Customize, extend or build upon these best practices to whatever degree you need to.
Note that throughout the following sections, best practices are italicized and enclosed in quotation marks.
Best practices for planning service-oriented projects
* Understand SOA: "Know the difference between building a service-oriented solution, versus one that only uses Web services."
The most common misperception relating to Service-Oriented Architecture I've encountered is that organizations believe that, by virtue of simply incorporating Web services, they are building SOA. This mistake tends to occur when the focus of a migration project is solely on the technology of the Web services platform. A transition, on a technical level, can still succeed; however, it misses the whole point of SOA. In fact, it does not even result in the creation of SOA -- it only accomplishes the integration of dev tools, standards, and products that utilize the Web services technology set.
I tend to refer to this type of architecture as one that "uses Web services," as opposed to being "service-oriented." Of course, there is always a middle ground where solutions are built (intentionally or inadvertently) with service-oriented design principles. Generally, however, organizations find themselves disappointed when apps based on the use of Web services do not reap the results promised by SOA. This can simply be avoided by fostering a thorough understanding of SOA concepts prior to developing corporate standards and apps around the use of Web services.
* Know how to use Web services: "Limit the scope of Web services in your production environment to the scope of your knowledge. If you know nothing, don't service-orient anything that matters."
Although the concept behind Web services has a great deal in common with traditional component-based design, it is still significantly different. Adding improperly designed Web services to your app may result in you having to redevelop them sooner than you might expect.
If you are delivering serious business functionality, you should hold off until you are confident in how Web services need to be integrated. Limit initial projects to low-risk prototypes and pilot apps, until you (and your project team) attain an adequate understanding of how Web services are best utilized within your technical environment.
* Move forward with a transition architecture: "Consider a transition architecture that only introduces service-oriented concepts, without the technology."
A low-risk solution is an option if you want to gain experience with service-oriented technologies and concepts, and you don't have pressing business requirements that rely on the proper delivery of Web services. You can start your transition by delivering your app the way you normally would, and then adding app proxies, or a custom designed facade (wrapper) to the functionality you'd like to expose via a service interface.
A benefit to this approach is that you can generally revert back to the traditional component-based model without much impact to your overall app design. If your project requires a risk assessment wherein the usage of Web services is classified as a significant risk, this can become the basis for a contingency plan.
If you're just toying with the idea of introducing Web services into your app design, but aren't really sure to what extent it makes sense to do so, you can also consider starting with a feasibility analysis. This will allow you to measure the pros and cons of the Web services platform, as they relate to your development project and your technical app environment.
Or, you could avoid Web services, and still build your app with a future SOA migration in mind. The XWIF modeling process [found] in Chapter 6 [of my book] provides a strategy for designing traditional component classes into service-oriented classes suitable for Web service encapsulation. These same remodeled classes can still be implemented within a non-service environment. The day you are ready to make the transition, you will already be halfway there.
* Leverage the legacy.
There are often very good reasons to replace or renew legacy environments in order to bring them into a contemporary framework. A service-oriented integration architecture, however, almost always provides an important alternative.
* Build on what you have: "Always consider reusing legacy logic before replacing it."
Through the use of adapters and a service interface layer designed for functional abstraction, Web services can let you take advantage of what you have. This can be a good first step to bringing app logic embedded in legacy systems into your integrated enterprise.
Compared to replacing a legacy environment altogether, leveraging existing systems is cost-effective, and the process of integration can be relatively expedient.
* Understand the limitations of a legacy foundation: "Define functional capacity boundaries around legacy applications, and do not integrate beyond."
There are challenges with bringing previously isolated apps into the interoperability loop. Although doing so can immediately broaden the resources shared by your enterprise, it can also severely tax a legacy environment not designed for external integration.
As long as you understand the boundaries within which you can incorporate legacy app logic, leveraging what you have makes a great deal of sense. Incidentally, typical EAI solutions (service-oriented or not) are based on the same principle of utilizing adapter architectures to include various legacy environments. Many mitigate the impact on legacy platforms through the use of intelligent adapters.
* Sorry, no refunds (Web services and your bottom line): "Budget for the range of expenses that follow Web services into an enterprise."
Web services are expensive. That is, good Web services require a great deal of work to ensure that they truly are "good." Each service you develop can potentially become an important part of your IT infrastructure. Not only can services expose legacy apps and various types of business (and reusable) functionality, they can represent and even enable entire business processes.
How a service is designed requires a solid knowledge of the business model within which it will operate, and the technologies upon which it will be built. Services that will form (or intend to participate in) a future SOA also need to be in alignment with the design strategy and accompanying standards that are part of the overall SOA implementation plan.
If you custom-develop services to add on to existing legacy environments, costs will typically be lower than if you start your integration by investing in enterprise service-oriented middleware products. Development costs can be especially moderate when using existing development tools that support the creation of Web services.
Also, because Web services open the door to new integration opportunities, the quality of the interface they expose is very important. Despite being classified as a loosely coupled technology, once heavily integrated into an enterprise, many dependencies upon service interfaces can still be created. Changing an interface after it has been established can be a costly (and messy) task, especially in environments that utilize service assemblies.
Doing it right, though, will reap tangible benefits. Integration effort within a relatively standardized SOA will drop significantly. Hooking new and legacy systems into an established Web services-enabled architecture will require a fraction of the effort and cost of traditional point-to-point integration projects. There are definite and measurable returns to be had on your investment, so it pays to get it right the first time.
* Build toward a future state: "Design a service-oriented solution to accommodate its probable migration path."
The built-in features of a Web services framework are there, whether you choose to use them or not. The foremost benefit of any service-oriented environment is the intrinsic potential for immediate and future interoperability. You can take advantage of this potential by designing application architectures for integration, even when not immediately requiring integration.
Fostering integration requires a change in design standards, app architecture development, and the overall mindset of the project team. For example, you can facilitate local requestors as well as future remote requestors by providing both coarse- and fine-grained interfaces based on standard naming and service description conventions.
To an extent, you can consider this new approach as building integration architectures, regardless of whether they will be integrating anything immediately. Perhaps a better suited term would be "integrate-able architectures."
* Use SOAs to streamline business models: "Service-oriented designs open up new opportunities for business automation. Rethink business models to take advantage of these opportunities."
If you find yourself amidst the technology surrounding Web services, don't lose sight of one of the most significant benefits this design platform can provide. By offering a more flexible, interoperable, and standardized model for hosting app functionality, SOAs provide an opportunity for you to rethink and improve your business processes.
For instance:
* A service-oriented architecture within your organization will increase the interoperability potential between legacy systems. This will allow you to re-evaluate various business processes that rely on multiple apps or data sources.
* An array of generic business and utility services will provide a number of ways to automate new parts of your business centers.
* Services can integrate with EAI solutions to deliver new business processes that, in turn, integrate existing business processes.
* Re-organize development resources: "Group development teams around logical business tasks."
A common mistake in development projects that incorporate a limited SOA is to have one team deliver the Web services, and the remaining team(s) develop the balance of the application. From a resourcing perspective this approach makes sense, because you have each team working with technologies that match their respective skill set. It can, however, create a disconnect between developers responsible for building parts of an application that deliver a logical unit of business functionality.
When you break an app down into its primary (or even secondary) business functions, you end up with the equivalent of a series of subprojects that collectively make up the app's feature set. Each of these subprojects will typically require the creation of a number of application components, some of which may be encapsulated within Web services. Development teams need to be grouped in accordance with these subprojects, so that the performance and functionality of individual business tasks can be streamlined.
If you have only one or two developers qualified to build Web services, then you should consider sharing them across more than one dev team. As long as they are actively participating with their respective teams, they will be able to optimize the Web services to best accommodate each business task.
To read more information on "Service-Oriented Architecture: A Field Guide to Integrating
XML and Web Services," please visit the Prentice Hall/Pearson PTR Web site at
http://www.phptr.com.