Home > Articles > Web Services > SOA

  • Print
  • + Share This
This chapter is from the book

This chapter is from the book

Service-Oriented Architecture

This section introduces the major concepts and definitions for services and SOA.

What Are Services?

Before we continue to discuss technology, let's discuss the notion of services and processes from a business perspective. Most organizations (whether commercial or government) provide services to customers, clients, citizens, employees, or partners. Let's look at an example of service orientation in practice.

As illustrated in Figure 1-4, bank tellers provide services to bank customers. Different tellers may offer different services, and some tellers may be specifically trained to provide certain types of services to the customer. Typical services include:

  • Account management (opening and closing accounts).

  • Loans (application processing, inquiries about terms and conditions, accepting payments).

  • Withdrawals, deposits, and transfers.

  • Foreign currency exchange.

Several tellers may offer the same set of services to provide load balancing and high availability. What happens behind the counter does not matter to the customer, as long as the service is completed. Processing a complex transaction may require the customer to visit several tellers and therefore implement a business process flow.

Figure 1.4Figure 1-4 Service analogy at the bank.

Behind the counter are the IT systems that automate the bank's services. The services are provided to the customer via the tellers. The services implemented by the IT systems must match and support the services provided by the tellers. A consistent approach to defining services on the IT systems that align with business functions and processes makes it easier for the IT systems to support the goals of the business and adapt more easily to providing the same service through humans, ATMs, and over the Web.

Figure 1-5 shows how the same service can be accessed from customers at the ATM, tellers on the office network, or Web users from their PCs. The services are designed and deployed to match the services that customers need. The implementation environments for the services don't matter; it's the service that's important. This figure also illustrates how two services can easily be combined to create another service, such as how the withdrawal and deposit service are composed into a transfer service.

Figure 1.5Figure 1-5 Accessing and composing services.

The definition of software services aligns with the business services that a bank offers to ensure smooth business operations and to help realize strategic goals such as providing ATM and Web access to banking services in addition to providing them in the branch office.

More complex applications can be composed from services, as we'll see, such as processing a purchase order or an insurance claim. Deploying services in the context of an SOA makes it easier to compose services into simple as well as complex applications, which can also be exposed as services that can be accessed by humans and IT systems alike.

What Is Service-Oriented Architecture?

A service-oriented architecture is a style of design that guides all aspects of creating and using business services throughout their lifecycle (from conception to retirement). An SOA is also a way to define and provision an IT infrastructure to allow different applications to exchange data and participate in business processes, regardless of the operating systems or programming languages underlying those applications.

An SOA can be thought of as an approach to building IT systems in which business services (i.e., the services that an organization provides to clients, customers, citizens, partners, employees, and other organizations) are the key organizing principle used to align IT systems with the needs of the business. In contrast, earlier approaches to building IT systems tended to directly use specific implementation environments such as object orientation, procedure orientation, and message orientation to solve these business problems, resulting in systems that were often tied to the features and functions of a particular execution environment technology such as CICS, IMS, CORBA, J2EE, and COM/DCOM.

Competitive Value of SOA

Businesses that successfully implement an SOA using Web services are likely to have a competitive advantage over those who do not because those who have services aligned with strategic IT business goals can react more quickly to changing business requirements than those who have IT systems aligned to a particular execution environment. It's easier to combine Web services, easier to change Web services compositions, and cheaper to change the Web services and XML data than it is to change execution environments. The advantages and benefits of SOA with Web services include a better return on investment for IT spending on projects, a faster time to results for the projects, and an ability to more quickly respond to changing business and government requirements. Any business that can implement an IT infrastructure that allows it to change more rapidly has an advantage over a business that cannot do the same. Furthermore, the use of an SOA for integration, business process management, and multi-channel access should allow any enterprise to create a more strategic IT environment, one that more closely matches the operational characteristics of the business.

SOA is the best way to capitalize on the value of service-oriented development. Service orientation reduces project costs and improves project success rates by adapting technology more naturally to the people who need to use it, rather than focusing (as the previous generations of IT systems have) on the technology itself, which forces people to adapt to the technology. The major difference between service-oriented development and previous approaches is that service orientation lets you focus on the description of the business problem, whereas previous approaches require you to focus more on the use of a specific execution environment technology. The way in which services are developed better aligns them with solving business problems than was the case with previous generations of technology.

The concept of SOA isn't new—what is new is the ability to mix and match execution environments, clearly separating the service interface from the execution technology, allowing IT departments to choose the best execution environment for each job (whether it's a new or existing application) and tying them together using a consistent architectural approach. Previous implementations of SOA were based on a single execution environment technology.

SOA Isn't New, So What Is?

Everyone is talking about SOA, although the concepts behind it aren't new. The idea of separating an interface from its implementation to create a software service definition has been well proven in J2EE, CORBA, and COM, and even DCE before that. But the ability to more cleanly and completely separate—basically by interpreting a text file—a service description from its execution environment is new. This ability is part of what Web concepts and technologies bring to Web services. The traditional implementations of the interface concept might not have considered such a "loose" separation because the performance implications are negative. However, in many cases, the performance issue is less important than the ability to more easily achieve interoperability, something the industry has long strived for but only partially achieved until now. The success or failure of SOA, however, does not depend upon the advance in IT software brought about by Web services. Rather, it depends upon a change in approach. The greater separation of interface from execution environment in Web services facilitates the separation of work responsibilities as well. Separating the service description from its technology implementation means that businesses can think about and plan IT investments around the realization of operational business considerations, as represented by the description, more so than the capabilities of any individual product or software technology chosen to execute the description. In this case, the description becomes the definition of a kind of lowest common denominator—a set of features and functions that everything can support. But this is achievable only if businesses change their way of thinking about IT. A service is something that's just available—just there for the consumption. Of course, this is an exaggeration; plenty of services and applications still have to be developed to reach the ideals of automating a business operation so quickly and flexibly that it just becomes a given, like office-software automation. No single software solution can address every requirement any more than the same computer system can run a car and calculate the trajectory for the Mars Rover. The same type of computer system cannot, and should not, operate an insulin pump and process orders for Amazon.com and tracks Web links for Google. The world is by its very nature diverse, and SOA with Web services embraces this diversity and provides the ability to create IT systems that map better to business operations than anything previously. However, this will take a significant change in thinking, not just for IT departments, but also for the entire software industry. It's equally hard to imagine that a single software vendor would be an expert in all aspects of software as it is to imagine that a single hardware vendor is an expert in all aspects of computing. Specialization is what the industry needs, along with the ability to create reusable assemblies of those components. In this vision of a future environment, software vendors are likely to become even more specialized, perhaps shipping assemblies of services instead of complete products. In an SOA-enabled world, enterprises very likely will have to learn not only to think about services as distinct from execution environments, but also how to assemble applications out of components from a variety of vendors.

The real value of SOA comes from the later stages of deployment, when new applications can be developed entirely, or almost entirely, by composing existing services. When new applications can be assembled out of a collection of existing, reusable services, the best value for effort can be realized (that is, the lowest cost and fastest time to results and best ROI). But it takes some time to reach this point, and significant investment in service development may be required.

It's easy to understand the benefit of reusing common business services such as customer name lookup, zip Code validation, or credit checking. In a pre-service oriented development environment, these functions might be performed by reusable code libraries or class libraries that are loaded or linked into new applications. In SOA-based applications, common functions such as these, as well as typical system functions such as security checks, transaction coordination, and auditing are instead implemented using services. Using services not only reduces the amount of deployed code, but it also reduces the management, maintenance, and support burden by centralizing the deployed code and managing access to it. However, the performance implications of accessing services instead of using internal functions must be assessed because using a service typically consumes more computing resources than reusable code libraries.

The key to a successful SOA is determining the correct design and function of the services in the reusable service library, which should ultimately reflect the operational characteristics of the organization, such as how grants are applied for, how cash is managed overnight, or how containers are transferred from ships to trucks. The operational characteristics of the business are what need to be automated, and the successful SOA project will ensure that the reusable software services are properly aligned with the operational business processes. The successful alignment of business services and their implementation in software ensures that operational business processes can be changed quickly and easily as external environmental changes cause an organization to adapt and evolve.

CORBA vs. Web Services for SOA

People familiar with the CORBA standard often remark that Web services are simply CORBA implemented using XML and note the number of features Web services are missing compared to CORBA. Many CORBA deployments are SOAs, in fact, and the original goals of CORBA are very similar to the goals of Web services. Cynics say that CORBA didn't succeed widely because of vendor politics, and there's some truth to that. However, CORBA also hurt itself in its early days by not defining a standard for interoperability. When asked about this, OMG presenters used to say, "It's an exercise left up to the vendors and the customers to work out." The implication, and sometimes the direct statement, was that interoperability didn't matter if you had a standard interface. Web services actually started with SOAP, which is an interoperability standard. Many people still use SOAP without WSDL, which is perfectly possible, indicating another contrast between the two. In CORBA, it's impossible to use the interoperability transport without the interface definition language (IDL)—in fact, everything is generated from the IDL. Many Web services toolkits also generate proxies and stubs from WSDL and also generate the SOAP messages. But this is an implementation choice, not part of the SOAP standard. From a technical perspective, it is certainly true that you can use CORBA for almost everything you can use Web services for. And for many applications, CORBA remains a better choice. However, from a human perspective, which is what really counts in the end, if someone is unfamiliar with CORBA or new to distributed computing, Web services are much easier to learn and use, and the missing features don't matter as much as the interoperability.

Challenges to Adoption

The main challenges to adoption of SOA include ensuring adequate staff training and maintaining the level of discipline required to ensure the services that are developed are reusable. Any technology, no matter how promising, can be abused and improperly used. Services have to be developed not simply for immediate benefit, but also (and perhaps primarily) for long-term benefit. To put it another way, the existence of an individual service isn't of much value unless it fits into a larger collection of services that can be consumed by multiple applications, and out of which multiple new applications can be composed. In addition, the definition of a reusable service is very difficult to get right the first time.

Another challenge is managing short-term costs. Building an SOA isn't cheap; reengineering existing systems costs money, and the payback becomes larger over time. It requires business analysts to define the business processes, systems architects to turn processes into specifications, software engineers to develop the new code, and project managers to track it all.

Another challenge is that some applications may need to be modified in order to participate in the SOA. Some applications might not have a callable interface that can be service-enabled. Some applications are only accessible via file transfer or batch data input and output and may need additional programs for the purpose of service-enablement.

Of course, incrementally adopting SOA and leveraging SOA where it will have the greatest business impact can mitigate the challenges and amortize their costs, especially when services can be used to solve tactical problems along the way. Part of adopting Web services and SOA therefore is to identify those projects that provide immediate value by solving an immediate problem (such as integrating J2EE and .NET Framework applications) and at the same time lay the foundation for a departmental or enterprise SOA.

What Web Services Are Good For

Sometimes in the Web services literature, you will see a lot of discussion about things that Web services are not good for, such as developing and deploying mission-critical applications. It's a mistake, however, to assume that they never will be good for this. Other times, you'll see talk about identifying the "golden copy" or "single reference" data item instance for a particular data type, such as customer ID or customer name. This is indeed a problem that needs solving, but it also isn't part of the job of the Web services. This means it needs to be solved at the SOA level rather than at the Web services level. These discussions often indicate unfamiliarity with Web services and the problems they are trying to solve. The same people who would never imagine that a single tool in a workshop could be used for every purpose often make the mistake of thinking that Web services must be good for everything that all other technologies that preceded them are good for. This represents thinking that each new technology wave somehow obsoletes the previous wave or takes over everything that came before. Web services are not just adding more technology to the problems of IT; they are proposing a different approach to solving some of the problems of IT, especially around integration, because of new capabilities offered by the technology. Web services are not really a replacement technology; they are not the same thing as a new programming language like Java or C#, which you could reasonably assume must include all the major features of other successful programming languages. Web services are not really a new middleware system in the sense that J2EE, CORBA, and the .NET Framework are middleware systems. Web services are XML-based interface technologies; they are not executable; they do not have an execution environment—they depend upon other technologies for their execution environments. If you don't rethink your approach to IT based on the features, functions, and capabilities of Web services, of course you're not going to get the value out of them that you should. Using Web services successfully requires a change in thinking about technology, not simply learning a new grammar for the same old way of building and deploying systems. Web services currently and will always require a mix of technologies. Therefore, Web services need to be understood in terms of what they add to the picture, not only in the context of what they replace.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020