Home > Articles > Web Services > SOA

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

This chapter is from the book

Service-Oriented Development

Software vendors have widely adopted the paradigm of service-oriented development based on Web services. Service-oriented development is complementary to the object-oriented, procedure-oriented, message-oriented, and database-oriented development approaches that preceded it.

Service-oriented development provides the following benefits:

  • Reuse—The ability to create services that are reusable in multiple applications.

  • Efficiency—The ability to quickly and easily create new services and new applications using a combination of new and old services, along with the ability to focus on the data to be shared rather than the implementation underneath.

  • Loose technology coupling—The ability to model services independently of their execution environment and create messages that can be sent to any service.

  • Division of responsibility—The ability to more easily allow business people to concentrate on business issues, technical people to concentrate on technology issues, and for both groups to collaborate using the service contract.

Developing a service is different from developing an object because a service is defined by the messages it exchanges with other services, rather than a method signature. A service must be defined at a higher level of abstraction (some might say at the lowest common denominator) than an object because it's possible to map a service definition to a procedure-oriented language such as COBOL or PL/I, or to a message queuing system such as JMS or MSMQ, as well as to an object-oriented system such as J2EE or the .NET Framework.

It's also important to understand the granularity at which the service is to be defined. A service normally defines a coarse-grained interface that accepts more data in a single invocation than an object and consumes more computing resources than an object because of the need to map to an execution environment, process the XML, and often access it remotely. Of course, object interfaces can be very coarse-grained. The point is that services are designed to solve interoperability problems between applications and for use in composing new applications or application systems, but not to create the detailed business logic for the applications.

It's possible to create an aggregation of Web services such that the published Web service encapsulates multiple other Web services. This allows a coarse-grained interface to be decomposed into a number of finer-grained services (or multiple finer-grained services to be composed into a coarse-grained interface). The coarse-grained service may make more sense to publish, while the finer-grained services may make more sense as "private" Web services that can be invoked only by the coarse-grained Web service.

Services are executed by exchanging messages according to one or more supported message exchange patterns (MEPs), such as request/response, one-way asynchronous, or publish/subscribe.

At a project level, an architect typically oversees the development of reusable services and identifies a means to store, manage, and retrieve service descriptions when and where they are needed. The reusable services layer insulates business operations such as "get customer" or "place an order" from variations in the underlying software platform implementations, just as Web servers and browsers insulate the World Wide Web from variations in operating systems and programming languages. The ability of reusable services to be composed into larger services quickly and easily is what provides the organization the benefits of process automation and the agility to respond to changing conditions.

How XML Helps Simplify Systems Development and Integration

The use of XML in Web services provides a clear separation between the definition of a service and its execution. This separation in the standards is intentional so that Web services can work with any software system. The XML representation, provided through an XML Schema, of the data types and structures of a service allows the developer to think about the data being passed among services without necessarily having to consider the details of a given service implementation. This represents a change in the nature of the integration problem from having to figure out the implementation of the service in order to talk to it. Whether the service's execution environment is an object, message queue, or stored procedure doesn't matter. The data is seen through the filter of a Web service, which includes a layer that maps the Web service to whatever execution environment is implementing the service.

One way to help accomplish this significant turnaround in the way we think about how to design, develop, and deploy applications using services may be to divide the responsibility within IT departments between those who:

  • Create the services—Dealing with the complexity of the underlying technology on which the service is being deployed and ensuring that the XML/Web services descriptions are what the service consumer needs and that they share the right data.

  • Consume the services—Assembling new composite applications and business process flows, ensuring that the shared data and process flows accurately reflect operational and strategic business requirements.

This potential division of responsibility more cleanly separates the technical issues from the business issues.

Organizational Implications of SOA

Previously, the same individuals in the IT department were responsible for understanding both business and technical functions—and this remains a classic problem for IT, that is, getting the same person or persons to bridge business and technology domains. To gain the full benefit of Web services, SOA, and BPM technologies, IT departments should consider the best organization and skill set mix. It's important when adopting a new architecture and a new technology to identify new roles and responsibilities. Among the important considerations is that technical staff must be able to reorient themselves from thinking about doing the entire job to doing a piece of the job that will be completed by someone else. A service needs to be developed within a larger context than an object or a procedure because it is more likely to be reused. In fact, defining services for reuse is probably the most important part of service orientation. To obtain their highest value, services must be developed in the context of other services and used in combination with them to build applications. This change in thinking is likely to require someone in a departmental or corporate leadership position to help review designs and ensure that they are in line with these new IT goals.

Service Abstraction

A service is a location on the network that has a machine-readable description of the messages it receives and optionally returns. A service is therefore defined in terms of the message exchange patterns it supports. A schema for the data contained in the message is used as the main part of the contract (i.e., description) established between a service requester and a service provider. Other items of metadata describe the network address for the service, the operations it supports, and its requirements for reliability, security, and transactionality.

Figure 1-2 illustrates the relationship among the parts of a service, including the description, the implementation, and the mapping layer between the two. The service implementation can be any execution environment for which Web services support is available. The service implementation is also called the executable agent. The executable agent is responsible for implementing the Web services processing model as defined in the various Web services specifications. The executable agent runs within the execution environment, which is typically a software system or programming language.

Figure 1.2Figure 1-2 Breakdown of service components.

An important part of the definition of a service is that its description is separated from its executable agent. One description might have multiple different executable agents associated with it. Similarly, one agent might support multiple descriptions. The description is separated from the execution environment using a mapping layer (sometimes also called a transformation layer). The mapping layer is often implemented using proxies and stubs. The mapping layer is responsible for accepting the message, transforming the XML data to the native format, and dispatching the data to the executable agent.

Web services roles include requester and provider. The service requester initiates the execution of a service by sending a message to a service provider. The service provider executes the service upon receipt of a message and returns the results, if any are specified, to the requester. A requester can be a provider, and vice versa, meaning an execution agent can play either or both roles.

As shown in Figure 1-3, one of the greatest benefits of service abstraction is its ability to easily access a variety of service types, including newly developed services, wrapped legacy applications, and applications composed of other services (both new and legacy).

Figure 1.3Figure 1-3 Requesting different types of services.

Separating the Service from the Product

Some software vendors still don't separate the idea of a service from the idea of an execution environment, and they continue to sell Web services implementations only as part of another, typically pre-existing product. This practice can make it more difficult to obtain the benefits of services because the products have features that may not be required to execute Web services and that may create incompatibilities if the products make the services dependent upon them.

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