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.