Home > Articles > Web Services > SOA

SOA Basics

  • Print
  • + Share This
This chapter from 100 SOA Questions answers the questions, what is SOA, is SOA an architectural style, what are fundamental constructs (the DNA) of SOA, what is the difference between a Web Service and an SOA service and what makes a project an SOA implementation?
This chapter is from the book
  • Delusions, errors, and lies are like huge, gaudy vessels, the rafters of which are rotten and worm-eaten, and those who embark in them are fated to be shipwrecked.
  • —Buddha

Service-oriented architecture (SOA) is defined in a number of ways, but not all definitions are equal, and not all definitions are complete. Instead of just providing another definition of SOA, this chapter describes the basic building blocks of SOA and looks at the value proposition of SOA from key stakeholder perspectives. Besides covering the basic building blocks of SOA, its DNA, and the value propositions of adopting SOA and its ultimate utility, this chapter describes what makes an implementation an SOA deployment. Specifically, this chapter addresses the following questions:

  1. What is SOA?
  2. Is SOA an architectural style?
  3. What are fundamental constructs (the DNA) of SOA?
  4. What is the difference between a Web Service and an SOA service?
  5. What makes a project an SOA implementation?

SOA Basics: Q&A

1. What Is SOA?

Numerous vendors, application providers, system integrators, architects, authors, analysts firms, and standards bodies provide definitions of SOA. The definitions of SOA are diverse. Most are complementary and do not conflict with each other. SOA has a variety of definitions because the definition is often tuned to a specific audience, as explaining SOA to a CEO is different from explaining SOA to a programmer. The term service orientation is often used synonymously with SOA, but just like SOA it has a wide range of interpretations. Service orientation is broader and represents a way of thinking about services in the context of business and IT. This book makes no distinction between SOA and service orientation and in some cases may use the two terms synonymously.

An agreed-upon definition for SOA eludes the industry. Anyone reading Wikipedia's definition page for SOA will see the challenges of trying to gain consensus on an SOA definition. Standards bodies, the OASIS group, and the Open Group have provided complementary but different SOA definitions. Presented with a blank sheet of paper, an artist sees a canvas. A poet might fill it with verse. An engineer seizes the opportunity to make a paper plane. Kids may see it as a future pile of spit wads. SOA is that blank sheet of paper.

To the chief information officer (CIO), SOA is a journey that promises to reduce the lifetime cost of the application portfolio, maximize return on investment (ROI) in both application and technology resources, and reduce lead times in delivering solutions to the business.

To the business executive, SOA is a set of services that can be exposed to their customers, partners, and other parts of the organization. Business capabilities, function, and business logic can be combined and recombined to serve the needs of the business now and tomorrow. Applications serve the business because they are composed of services that can be quickly modified or redeployed in new business contexts, allowing the business to quickly respond to changing customer needs, business opportunities, and market conditions.

To the business analyst, SOA is a way of unlocking value, because business processes are no longer locked in application silos. Applications no longer operate as inhibitors to changing business needs.

To the chief architect or enterprise architect, SOA is a means to create dynamic, highly configurable and collaborative applications built for change. SOA reduces IT complexity and rigidity. SOA becomes the solution to stop the gradual entropy that makes applications brittle and difficult to change. SOA reduces lead times and costs because reduced complexity makes modifying and testing applications easier when they are structured using services.

To the IT architect, SOA is the architectural solution for integrating diverse systems by providing an architectural style that promotes loose coupling and reuse. Many IT architects think they have seen this style before with earlier architectural initiatives such as DCE, the Distributed Computing Environment, and CORBA, the Common Object Request Broker Architecture.

To the developer, SOA is a programming model or paradigm where web services and contracts becomes a dominant design for interoperability. It is a web service when it uses a Web Service Description Language (WSDL) or equivalent specification for describing the service. Web services enable organizations to communicate information, using messages, without intimate knowledge of each other's IT systems.

Delivering on the promises of SOA (improved business agility, maximized ROI, reduced IT complexity and rigidity, reduced costs, reduced lead times, reduced risk, new opportunities to deliver value, increased participation in value networks, and incremental implementation) requires you take a holistic view of SOA. If we limit the view of SOA to a single stakeholder (e.g., IT architect, developer, or business analyst) the benefits will not accrue because SOA then just becomes one in a long list of overhyped technologies rather than a novel approach to building flexible business solutions.

2. Is SOA an Architectural Style?

SOA is often seen as an architectural style that has been around for years. Figure 1.1 shows the architectural style of SOA. In this scenario, a service consumer invokes or uses a service. The service consumer uses the service description to obtain necessary information about the provider service (e.g., account service) to be consumed. The service description provides the binding information so the consumer can connect to the service, and the description identifies the various operations (e.g., open or close account) available from the provider service. A broker can be used to find the service using a registry that houses information about the service and its location.

Figure 1.1

Figure 1.1 SOA as an architecture style

In Figure 1.1, it is difficult to determine how the architecture style of SOA enables the strategic benefits of SOA, such as lowering the lifetime cost of an application or bringing faster time to market or making applications resilient to change. SOA as an architectural style often makes an SOA project solely an IT endeavor where the strategic business benefits of SOA no longer become the focus or measured outcomes. Benefits of process flexibility, time-to-market savings, lower costs, and others can be achieved with SOA, but only if we holistically adopt all stakeholder views of SOA and its application and pursue SOA adoption accordingly. When pundits, architects, consultants, or executives define SOA as a pure technology play or as solely an architectural style, they relegate it to the realm of IT science projects, overhyped technologies, and a marketing strategy rather than a novel approach to building flexible business solutions.

An understanding of SOA is enhanced with the next question and answer. By looking at the SOA building blocks of SOA, you can gain a fuller understanding of what SOA is and how to realize its promised benefits.

3. What Are the Fundamental Constructs (the DNA) of SOA?

The most basic construct or building block of SOA is a service. Software engineering over the years has evolved from procedural to structured programming to object-oriented programming to component-based development and now to service oriented. Figure 1.2 illustrates the different levels of abstraction from objects to services. Each evolution of abstraction builds on the previous, and SOA embraces the best practices of object and component development.

Figure 1.2

Figure 1.2 Levels of abstraction

To see architectural style of SOA, refer to Figure 1.1. That illustration shows the fundamental constructs of SOA, such as the service consumer and the service provider and their relationship. The consumer invokes a service, the business functionality, by contract. The provider of the service defines the contract as a service description. An intermediary, such as a broker, uses a registry to find or search for published services. Service consumer, service provider, service description, service broker, and a registry are all part of the DNA of SOA.

A service in SOA is the logical, self-contained business function. Services in SOA have the following attributes:

  • Stateless: SOA services neither remember the last thing they were asked to do nor do they care what the next is. Services are not dependent on the context or state of other services, only on their functionality. Talking on the telephone is stateful, whereas posting a letter is stateless. The World Wide Web provides an excellent example, where each request from a user for a web page or URL results in the requested pages being served, but without the web server remembering the request later. Each request or communication is discrete and unrelated to requests that precede or follow it.
  • Discoverable: A service must be discoverable by potential consumers of the service. After all, if a service is not known to exist, it is unlikely ever to be used. Services are published or exposed by service providers in the SOA service directory, from which they are discovered and invoked by service consumers.
  • Self-describing: The SOA service interface describes, exposes, and provides an entry point to the service. The interface contains all the information a service consumer needs to discover and connect to the service, without ever requiring the consumer to understand (or even see) the technical implementation details.
  • Composable: SOA services are, by nature, composite. They can be composed from other services and, in turn, can be combined with other services to compose new business solutions.
  • Loose coupling: Loose coupling allows the concerns of application features to be separated into independent pieces. This separation of concern provides a mechanism for one service to call another without being tightly bound to it. Separation of concerns is achieved by establishing boundaries, where a boundary is any logical or physical separation that delineates a given set of responsibilities. For example, an account service has open account, authorization, and audit features representing delineations of responsibilities and three separations of concerns.
  • Governed by policy: Services are built by contract. Relationships between services (and between services and service domains) are governed by policies and service-level agreements (SLAs), promoting process consistency and reducing complexity.
  • Independent location, language, and protocol: Services are designed to be location transparent and protocol/platform independent (generally speaking, accessible by any authorized user, on any platform, from any location).

In addition, services in a service-oriented architecture typically have the following characteristics:

  • Coarse-grained: Services are typically coarse-grained business functions. Granularity is a statement of functional richness for a service—the more coarse-grained a service is, the richer the function offered by the service. Coarse-grained services reduce complexity for system developers by limiting the steps necessary to fulfill a given business function, and they reduce strain on system resources by limiting the "chattiness" of the electronic conversation. Applications by nature are coarse-grained because they encompass a large set of functionality; the components that comprise applications would be fine-grained. Similarly, within an application, a service such as "get account information" (which returns name, account number, and address) could be described as coarse-grained, whereas a service to "get account number" could be described as fine-grained.
  • Asynchronous: Asynchronous communication is not required of an SOA service, but it does increase system scalability through asynchronous behavior and messaging techniques. Unpredictable network latency and high communications costs can slow response times in an SOA environment, due to the distributed nature of services. Asynchronous behavior and messaging allow a service to issue a service request and then continue processing until the service provider returns a response.

Viewed from the top down, SOA comprises the following constructs, as illustrated in Figure 1.3: consumer, business processes, services, components, information, rules, and policies. Consumers allow invocation or composition of services at the consumer layer through social software, mashups, business processes, or other systems. Business processes represent the flows of activities required to complete a business process; they are compositions of services targeted to achieve business goals. Services are the main structuring element required by a service consumer and are provided by the service provider. Services offer functionality and quality of service, both of which are externalized within service descriptions and policies. Services can be composed of other services, thus making them composite services. Components realize not only the functionality of the services they expose but also ensure their quality of service. Information flows between the layers (for example, consumer, process, and service) and within a layer. Lastly, rules and policies exist for services, components, and flows.

Figure 1.3

Figure 1.3 Top-down view of SOA constructs

Although objects are illustrated in Figure 1.3, the word object does not imply an implementation of object orientation, because the object can easily be a procedural subroutine implemented in a multitude of languages as easily as it can be implemented in a object-oriented programming language. SOA must have services and components that realize the services. Processes or flows may string services together to fulfill a step or activity of a business process. For example a transfer of funds service may string together both a debit and credit account service.

There is also a technology view of SOA. Technology enables SOA, makes it efficient, and optimizes the implementation, but SOA is not defined by the technologies chosen for implementation. Instead, SOA is defined by providing a uniform means to offer, discover, interact with, and use capabilities (services) to produce desired effects consistent with measurable expectations.

The major technologies associated with SOA include business-focused tools, software construction tools, and middleware technologies. Figure 1.4 illustrates the basic technology building blocks for SOA. Tools are required for SOA addressing design-time and runtime scenarios. Business stakeholders use business-focused tools for modeling and analysis of business processes and flows, and they will also use business activity monitoring technology to gain insights into business performance of processes and workflow. IT practitioners use a set of tools for development of business applications and for managing the operating environment addressing integration, monitoring, and security.

Figure 1.4

Figure 1.4 Business and IT tools for SOA

The DNA of SOA will most likely be further investigated and defined by standards groups actively involved in defining an SOA ontology. For example, see www.opengroup.org/projects/soa-ontology/. Such an ontology will address SOA key concepts, including services, service contracts, service interfaces, composition (orchestration, choreography, and collaboration), processes, service compositions, policies, and events. Each of these makes up the DNA of SOA.

4. What Is the Difference Between a Web Service and an SOA Service?

The distinction between business services or SOA services versus a web service is not often articulated, and many equate the two as being the same. SOA services can be realized as web services, but not all web services are equal to SOA services. Web services represent the use of both a published standard and a set of technologies for invocation and interoperability. SOA services are services that fulfill a key step or activity of a business process and can be described as business services and are often exposed as web services.

Figure 1.3 illustrates both an SOA service and a web service. The picture shows the difference between SOA and web services at runtime (i.e., implementation level) and at design time. The web service is illustrated on the right side of Figure 1.5, specifically the Web Services Description Language (WSDL) and its attributes such as port types and operations. The attribute that makes it a web service is the use of WSDL or equivalent.

Figure 1.5

Figure 1.5 SOA service and web service

In design, we identify and specify a service that provides the design, or we identify and specify interfaces that include method specifications. The combination of the definition of the method and the interface at design time is what we refer to as a service from an SOA perspective. Use cases can be used to capture the functional requirements for a service. Figure 1.5 contrasts the differences between a service in SOA and a web service. Both SOA services and web services are part of the DNA of SOA.

In an SOA, business processes, activities, and workflow are broken down into constituent functional elements called services. They can be accessed and used directly by applications, or they can be mixed and matched with other services to create new business capabilities. Business services or SOA services are reusable business capabilities. Examples in banking include open account or change address. For transportation, it might be get reservation or hold reservation, and with loan processing, get loan, apply for loan, and update address are examples of business services. Business processes are also key constructs of SOA, part of its DNA.

5. What Makes a Project an SOA Implementation?

The deployment of services makes a project an SOA implementation, where a service is defined in the preceding answer as a web service or an SOA service. The use of the Web Service Description Language (WSDL) or equivalent makes a service a web service. An SOA service must satisfy the criteria described in the Answer 2; namely, an SOA service must be stateless; discoverable; self-describing; composable; loosely coupled; governed; and independent of location, language, or protocol. That is, the use of services alone makes the project or implementation an SOA implementation. However, an SOA implementation may not accrue the desired benefits of SOA around cost savings, reuse, time to market, or flexibility.

Services can have different levels of maturity. For example, services can be ad hoc in their design and implementation where a WSDL façade is implemented to make function accessible to other systems or applications. Services can also be architected where service modeling and governance are used to maximize service reuse.

The implementation of SOA technologies without a deployment of one or more services could also be defined as an SOA implementation. This would be atypical because middleware and infrastructure implementations (e.g., a registry or enterprise service bus) would be implemented in conjunction with the deployment of services.

Just as services have different levels of maturity, so do SOA adoptions within an organization. Some SOA adoptions require a program of projects to address a journey of increasing maturity to achieve strategic SOA goals of building systems for change, infusing flexibility as an attribute of systems, or reducing the lifetime costs of applications and infrastructure. In this case, the program comprises a series of SOA projects that incrementally raise the maturity of SOA in an organization and along the way enable the realization of the strategic SOA benefits.

Often, because of overselling of SOA, organization leaders, managers, and executives wrongly believe that the benefits of SOA automatically accrue when an SOA implementation occurs. SOA has varied and diverse definitions, and hence its implementations are equally varied. So, organizations seeking to accrue any of the promised benefits of SOA must do more than focus on SOA implementations. That is, each expected benefit of SOA requires a different level of SOA maturity. For example, if the goal is only to reduce the cycle time of a business process that deals with external partners, exposing web services may be the only necessary SOA adoption. However, if the business goal is to reduce time to market for new products, this requires a broader adoption of SOA that addresses reusable services, structuring of applications using services, improving integration using services, and aspects of SOA governance to address service sharing, funding, and ownership.

  • + 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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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