Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services. Pt. 1.
Service-Oriented Architecture: Chapter 13: Thirty best practices for integrating Web services, Pt. 1.
"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."
Best practices for planning service-oriented projects page 334eb services introduce technology layers that reside over those already established by the XML platform. Therefore, the best practices for XML provided in the previous chapter also apply to service-oriented environments. Additionally, the contents of this chapter can be further supplemented by extracting best practices from the design and modeling strategies in Chapter 6.
13.1 Best practices for planning service-oriented projects
13.1.1 Know when to use Web services
“First define the extent to which you want to
use Web services before developing them. Services can be phased in at different
levels, allowing you to customize an adoption strategy.”
If you know that Web services will be a strategic part of your
enterprise, then you need to start somewhere. A single application project,
for instance, provides a low-risk opportunity for taking that first
step. You will be able to integrate Web services to a limited extent and
in a controlled manner. The key word here is “limited,” because
you do not want to go too far with a non-standardized integration effort.
Additional reasons to consider Web services include:
- The global IT industry is embracing and supporting Web services.
By incorporating them sooner, your team will gain an understanding of
an important platform shift that affects application architecture and
technology.
- Use of Web services does not require an entirely new application
architecture. Their loosely coupled design allows you to add a modest
amount of simple services, without much impact on the rest of the application.
- If you are considering or already using a service-oriented design
or business model, you definitely will need to take a serious look
at Web services. The benefits of incorporating service-oriented
paradigms within your enterprise can motivate the technical migration
to a Web services framework.
•Many current development tools already support the creation
of Web services, and several shield the developer from the low-level implementation
details. This eases the learning curve and allows for a faster adoption
of Web service-related technologies.
13.1.2 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 application 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 applications, until
you (and your project team) attain an adequate understanding of how Web
services are best utilized within your technical environment.
13.1.3 Know when to avoid Web services
“Even though Web services are becoming an important
part of the IT mainstream, you should begin incorporating them only where
you know they will add value.”
If you don’t think that Web services will become a part
of your enterprise environment anytime in the near future, then it may be
premature to add them now. Technologies driving the Web services platform
will continue to evolve, as will the front- and back-end products that support
them.
Additional reasons to consider avoiding Web services in the short-term,
include:
- The base Web service technologies (SOAP, WSDL, UDDI) are fairly
established and robust, but vendor support can vary significantly
for second-generation specifications. You may be better off waiting
for certain standards to receive industry-wide support.
- Though development tools that support Web services will auto-generate
a great deal of the markup, they will not assist in optimizing your application
design. Having your developers simply attach one or two Web services to
an existing application, without a real understanding of the technology
behind them, could lead to a convoluted and weakened architecture.
- Some tools add proprietary extensions that will create dependencies
on a vendor-specific platform. The long-term implications of these
extensions need to be understood fully before too much of your application
relies on them. Otherwise, opportunities for future interoperability may
be compromised.
- Incorporating Web services may simply not be a requirement for
autonomous application environments. Web services become a much more important
consideration when taking interoperability requirements into account.
13.1.1 Know when to use Web services
“First define the extent to which you want to use Web services before developing them. Services can be phased in at different levels, allowing you to customize an adoption strategy.”
If you know that Web services will be a strategic part of your enterprise, then you need to start somewhere. A single application project, for instance, provides a low-risk opportunity for taking that first step. You will be able to integrate Web services to a limited extent and in a controlled manner. The key word here is “limited,” because you do not want to go too far with a non-standardized integration effort.
Additional reasons to consider Web services include:
- The global IT industry is embracing and supporting Web services. By incorporating them sooner, your team will gain an understanding of an important platform shift that affects application architecture and technology.
- Use of Web services does not require an entirely new application architecture. Their loosely coupled design allows you to add a modest amount of simple services, without much impact on the rest of the application.
- If you are considering or already using a service-oriented design or business model, you definitely will need to take a serious look at Web services. The benefits of incorporating service-oriented paradigms within your enterprise can motivate the technical migration to a Web services framework.
•Many current development tools already support the creation of Web services, and several shield the developer from the low-level implementation details. This eases the learning curve and allows for a faster adoption of Web service-related technologies.
13.1.2 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 application 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 applications, until you (and your project team) attain an adequate understanding of how Web services are best utilized within your technical environment.
13.1.3 Know when to avoid Web services
“Even though Web services are becoming an important part of the IT mainstream, you should begin incorporating them only where you know they will add value.”
If you don’t think that Web services will become a part of your enterprise environment anytime in the near future, then it may be premature to add them now. Technologies driving the Web services platform will continue to evolve, as will the front- and back-end products that support them.
Additional reasons to consider avoiding Web services in the short-term, include:
- The base Web service technologies (SOAP, WSDL, UDDI) are fairly established and robust, but vendor support can vary significantly for second-generation specifications. You may be better off waiting for certain standards to receive industry-wide support.
- Though development tools that support Web services will auto-generate a great deal of the markup, they will not assist in optimizing your application design. Having your developers simply attach one or two Web services to an existing application, without a real understanding of the technology behind them, could lead to a convoluted and weakened architecture.
- Some tools add proprietary extensions that will create dependencies on a vendor-specific platform. The long-term implications of these extensions need to be understood fully before too much of your application relies on them. Otherwise, opportunities for future interoperability may be compromised.
- Incorporating Web services may simply not be a requirement for autonomous application environments. Web services become a much more important consideration when taking interoperability requirements into account.
Created: March 27, 2003
Revised: February 21, 2004
URL: http://webreference.com/programming/soa/1
Find a programming school near you
