Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 2.
Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services, Pt. 2.
"This chapter is from the book "Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services" by Thomas Erl. (ISBN 0131428985). This chapter is posted with permission from "Prentice Hall PTR."
13.3.4 Understand the limitations of your platformWhile traveling the roads that lead to an SOA, you are bound to run into the odd pothole or roadblock. As key industry standards continue to mature, so does the feature set required for Web services to become fully capable of representing and expressing sophisticated business logic in enterprise environments.
Until the second generation of Web services speciﬁcations is fully evolved, however, there remains a rather volatile transition period, as many middleware and development platforms compensate for the absence or immaturity of these standards by supplying solutions of their own.
Proprietary extensions (the potholes) “Deﬁne and work within the boundaries of your development platform.”
Several platforms supplement core Web services standards with proprietary extensions. Often these new features will be based on draft versions of speciﬁcations expected to become industry standards. The extent to which standards are supported, however, can vary.
When considering the use of vendor-speciﬁc extensions, make sure you understand how they are being implemented, and what dependencies they impose. Keep in mind that if you commit to using them, you may need to migrate your services away from these extensions at some point in the future.
In the meantime, however, they may very well address your immediate requirements, while allowing you to proceed with a service-oriented application design.
Exclusive proprietary extensions (the roadblocks) “If development platform boundaries are too restrictive, reconsider the platform.”
Some development platforms provide extensions to Web services at the cost of requiring that all requestors of the service be built using the same technologies. This not only defeats the purpose of designing service-oriented applications, it ties you to a platform that offers little more than traditional component-based environments.
Within a controlled environment, these features may be attractive. If open interoperability is one of your future goals, though, it’s time to make a U-turn.
13.3.5 Use abstraction to protect legacy endpoints from change
The service interface layer can give you a great deal of ﬂexibility in how you continue evolving integrated legacy applications. Since the integration layer acts as an intermediary between previously tightly bound legacy applications, a level of decoupling is achieved. This makes the Web service the only contact point for either legacy environment.
Use abstraction to improve conﬁguration management “Alter conﬁguration management procedures around the abstraction beneﬁt introduced by the service interface layer.”
A side beneﬁt to the loose coupling introduced by the service integration layer is improved conﬁguration management of integrated legacy applications.
Application A is upgraded without affecting application B.
As shown in Figure 13.3, you can upgrade application A without requiring changes to application B. However, depending on the nature of the upgrade, application A’s Web service may be affected. Modifying the integration layer, though, tends to be much easier than making changes to legacy logic.
Although this aspect of an SOA isn’t the ﬁrst beneﬁt that comes to mind, it can have major implications on how you administer and maintain applications in your enterprise.
Use abstraction to support wholesale application changes “Take advantage of the service integration layer by more aggressively evolving integrated legacy environments.”
The level of abstraction that can be provided by service-oriented integration architec
tures can signiﬁcantly reduce the impact of platform migrations. Since the two applications displayed in Figure 13.4 only know of service endpoints, you can replace application A entirely without any changes required to application B. Any required modiﬁcations to application A’s Web service almost always will be less disruptive than changes to application B’s integration channel.
Created: March 27, 2003
Revised: February 21, 2004