Soa chapter 5

Web Services and Primitive SOA
By :Amar Nath MTech NIT Rourkela
Chapter 5

Contemporary SOA is intrinsically reliant on Web services so much so that Web
services concepts and technology used to actualize service-orientation have
influenced and contributed to a number of the common SOA characteristics we
identified in Chapter 3
Figure 5.1: The structural relationship between sections
in Chapters 3 and 5.

•
“A technology framework is a collection of things. It can include one or more architectures,
technologies, concepts, models, and even sub-frameworks”.
Specifically, this framework is characterized by:
1. an abstract (vendor-neutral) existence defined by standards organizations and implemented by
(proprietary) technology platforms.
2. core building blocks that include Web services, service descriptions, and messages
3. a communications agreement centered around service descriptions based on WSDL
4. a messaging framework comprised of SOAP technology and concepts
5. a service description registration and discovery architecture sometimes realized through UDDI
6. a well-defined architecture that supports messaging patterns and compositions (covered in Chapter
6)
7. a second generation of Web services extensions (also known as the WS-*specifications) continually
broadening its underlying feature-set (covered in Chapters 6 and 7)
The Web services framework

Services (as Web services)
• In previous section we introduced the concept of services and how they
provide a means of encapsulating various extents of logic.
• Manifesting services in real world automation solutions requires the use of
a technology capable of preserving fundamental service-orientation, while
implementing real world business functionality.
• Web services provide the potential of fulfilling these primitive
requirements, but they need to be intentionally designed to do so.
• This is because the Web services framework is flexible and adaptable.
Web services can be designed to duplicate the behavior and functionality
found in proprietary distributed systems, or they can be designed to be
fully SOA-compliant.
• This flexibility has allowed Web services to become part of many existing
application environments and has been one of the reasons behind their
popularity

Copyright © Pearson Education, Inc.
Service Roles
• A Web service is capable of assuming different roles, depending on the
context within which it is used.
• For example, a service can act as the initiator, relayer, or the recipient of
a message.
• A service is therefore not labeled exclusively as a client or server, but
instead as a unit of software capable of altering its role, depending on its
processing responsibility in a given scenario.
Different Role as Follows
• Service provider
• The Web service is invoked via an external source, such as a
service requestor (Figure 5.2).
• The Web service provides a published service description offering
information about its features and behavior
• The service provider role is synonymous with the server role in the
classic client-server architecture.

Figure 5.2: As the recipient of a request message, the Web service is
classified as a service provider.
Some Terms used in service context.
• service provider entity (the organization or individual providing the
Web service)
• service provider agent (the Web service itself, acting as an agent
on behalf of its owner)

Service Requestor
• Any unit of processing logic capable of issuing a request message that can
be understood by the service provider is classified as a service requestor .
• A Web service is always a service provider but also can act as a service
requestor.
A Web service takes on the service requestor role under the
following circumstances:
• The Web service invokes a service provider by sending it a message
• The Web service searches for and assesses the most suitable service
provider by studying available service descriptions. (Service descriptions and
service registries are covered in the Service descriptions
service requestor entity (the organization or individual requesting the Web
service)
service requestor agent (the Web service itself, acting as an agent on behalf of
its owner)

Figure 5.3: The sender of the request message
is classified as a service requestor.

Figure 5.4: TLS and RailCo services swapping roles in different but related
message exchanges

Figure 5.5: The intermediary service transitions through service
provider and service requestor roles while processing a message.

Figure 5.6: A passive intermediary service processing a message without
altering its contents.

Figure 5.7: An active intermediary service.

Figure 5.8: Web services acting as initial
sender and ultimate receiver.

Figure 5.9: The TLS Load Balancing Service acting as an intermediary
between the RailCo initial sender and the TLS ultimate receiver.

Figure 5.10: A service composition consisting of four members.

Figure 5.11: The Accounts Payable Service enlisting other TLS
services in a service composition.

Service models
“The manner in which services are being utilized in the real world, though, has
led to a classification based on the nature of the application logic they provide, as
well as their business-related roles within the overall solution. These
classifications are known as service models” .
•It is important to note that a service can and frequently does belong to more
than one service model.
“Type of Service Model”
• Business service model,
•Utility service model,
•Controller service model
Business service model,
Within an SOA, the business service represents the most fundamental building
block. It encapsulates a distinct set of business logic within a well-
defined functional boundary. It is fully autonomous but still not limited to
executing in isolation, as business services are frequently expected to participate
in service compositions.

Business services are used within SOAs as follows:
•as fundamental building blocks for the representation of business logic
•to represent a corporate entity or information set
•to represent business process logic
•as service composition members
Utility service model
“Any generic Web service or service agent designed for potential reuse can
be classified as a utility service” .
Utility services are used within SOAs as follows:
•as services that enable the characteristic of reuse within SOA
•as solution-agnostic intermediary services
•as services that promote the intrinsic interoperability characteristic of SOA
•as the services with the highest degree of autonomy

• Case Study
In the examples we've gone through so far in this chapter, we've described eight
Web services. Six of these are business services, while the other two are utility
services, as follows:
Accounts Payable Service = business service
Internal Policy Service = utility service
Invoice Submission Service = business service
Ledger Service = business service
Load Balancing Service = utility service
Order Fulfillment Service = business service
Purchase Order Service = business service
Vendor Profile Service = business service
The Load Balancing and Internal Policy Services are classified as utility services
because they provide generic functionality that can be reused by different types of
applications. The application logic of the remaining services is specific to a given
business task or solution, which makes them business-centric services.

Controller service model
• Service compositions are comprised of a set of independent services that each
contribute to the execution of the overall business task.
• The assembly and coordination of these services is often a task in itself and
one that can be assigned as the primary function of a dedicated service or as
the secondary function of a service that is fully capable of executing a business
task independently.
• The controller service fulfills this role, acting as the parent service to service
composition members.
Controller services are used within SOAs as follows:
• to support and implement the principle of composability
• to leverage reuse opportunities
• to support autonomy in other services
Note that controller services themselves can become subordinate service
composition members. In this case the composition coordinated by a controller
is, in its entirety, composed into a larger composition. In this situation there
may be a master controller service that acts as the parent to the entire service
composition, as well as a sub-controller, responsible for coordinating a portion
of the composition (Figure 5.12).

Figure 5.12: A service composition consisting of a master
controller, a sub-controller, four business services, and one
utility service.

Figure 5.13: The Accounts Payable Service acting as a business and
controller service, composing two other business services.

Service descriptions (with WSDL)
 This part of SOA provides the key ingredient to establishing a consistently
loosely coupled form of communication between services implemented as
Web services.
• For this purpose, description documents are required to accompany any
service wanting to act as an ultimate receiver. The primary service
description document is the WSDL definition (Figure 5.14).

Figure 5.14: WSDL definitions enable loose coupling between services.

Case Study
 For RailCo to design its B2B Web services in full compliance with the TLS
services, RailCo acquires the WSDL service description published by TLS for
their Accounts Payable Service.
 This definition file then is used by developers to build the Invoice Submission
Service so that it can process SOAP messages in accordance with the service
interface requirements defined in the TLS service descriptions.
 Further, RailCo provides TLS with a copy of the WSDL definition for the RailCo
Order Fulfillment Service. TLS registers this service description and adds it to the
list of vendor endpoints that will receive electronic purchase orders. (Figure 5.15
illustrates both scenarios.)

Figure 5.15: Each service requestor is using the WSDL of a
service provider to ensure that messages sent will be
understood and accepted.

Figure 5.16: WSDL document consisting of abstract and concrete parts
that collectively describe a service endpoint.
Service endpoints and service descriptions/WSDL service definition
A WSDL describes the point of contact for a service provider, also known as
the service endpoint or just endpoint . It provides a formal definition of the endpoint
interface (so that requestors wishing to communicate with the service provider know
exactly how to structure request messages) and also establishes the physical location
(address) of the service.

Abstract description
An abstract description establishes the interface characteristics of the Web
service without any reference to the technology used to host or enable a Web
service to transmit messages. By separating this information, the integrity of the
service description can be preserved regardless of what changes might occur
to the underlying technology platform.
portType, operation, and message
The parent portType section of an abstract description provides a high-level
view of the service interface by sorting the messages a service can process into
groups of functions known as operations .
Web services rely exclusively on messaging-based communication, parameters
are represented as messages. Therefore, an operation consists of a set of input
and output messages .
The term "portType" is being renamed to "interface" in version 2.0 of the WSDL
specification.

Concrete description
• For a Web service to be able to execute any of its logic, it needs for its
abstract interface definition to be connected to some real, implemented
technology.
• Because the execution of service application logic always involves
communication, the abstract Web service interface needs to be connected to
a physical transport protocol.
binding, port, and service
• A WSDL description's binding describes the requirements for a service to
establish physical connections or for connections to be established with the
service.
• In other words, a binding represents one possible transport technology the
service can use to communicate.
• SOAP is the most common form of binding, but others also are supported. A
binding can apply to an entire interface or just a specific operation.
The term "port" is being renamed "endpoint" in version 2.0 of the WSDL
specification.

Metadata and service contracts
We have up to three separate documents that each describe an aspect of a service:
•WSDL definition
•XSD schema
•Policy
Each of these three service description documents can be classified as
service metadata , as each provides information about the service.
Service description documents can be collectively viewed as establishing a service
contract a set of conditions that must be met and accepted by a potential service
requestor to enable successful communication.
Note that a service contract can refer to additional documents or agreements not
expressed by service descriptions. For example, a Service Level Agreement (SLA)
agreed upon by the respective owners of a service provider and its requestor can
be considered part of an overall service contract (Figure 5.17).

Figure 5.17: A service contract comprised of a collection of service
descriptions and possibly additional documents.

Semantic descriptions
Most of the metadata currently provided by services focuses
on expressing technical information related to data representation and processing
requirements. However, these service description documents generally do
not prove useful in explaining details about a service's behavioral characteristics.
In fact, the most challenging part of providing a complete description of a Web
service is in communicating its semantic qualities.
Examples of service semantics include:
•how a service behaves under certain conditions
•how a service will respond to a specific condition
•what specific tasks the service is most suited for
Semantic information is usually of greater importance when dealing with
external service providers, where your knowledge of another party's service is
limited to the information the service owner decides to publish. But even within
organizational boundaries, semantic characteristics tend to take on greater
relevance as the amount of internal Web services grows.

Service description advertisement and
discovery
As we've established, the sole requirement for one service to contact another is
access to the other service's description.
As the amount of services increases within and outside of organizations,
mechanisms for advertising and discovering service descriptions may become
necessary.
For example, central directories and registries become an option to keep track of
the many service descriptions that become available. These repositories allow
humans (and even service requestors) to:
• locate the latest versions of known service descriptions
• discover new Web services that meet certain criteria
• When the initial set of Web services standards emerged, this eventuality
was taken into account.
This is why UDDI formed part of the first generation of Web services standards.
Though not yet commonly implemented, UDDI provides us with a registry model
worth describing.

Private and public registries
UDDI specifies a relatively accepted standard for structuring registries that
keep track of service descriptions (Figure 5.18). These registries can be
searched manually and accessed programmatically via a standardized API.
Figure 5.18: Service description locations centralized in a registry.

Public registries accept registrations from any organizations, regardless of
whether they have Web services to offer. Once signed up, organizations
acting as service provider entities can register their services.
Private registries can be implemented within organization boundaries to
provide a central repository for descriptions of all services the organization
develops, leases, or purchases.

Figure 5.19: The basic structure of a UDDI business entity record.

Figure 5.20: The TLS service registry
containing pointers to current TLS WSDL
definitions.

Figure 5.21: The basic structure
of a SOAP message

Figure 5.22: The RailCo Invoice Submission Service packaging the
contents of three documents into one SOAP message.

Figure 5.23: A SOAP node
transmitting a SOAP message
received by the service logic.

Figure 5.24: The positioning of SOAP ondes within a message
transmission between RailCo and TLS.

Figure 5.25: Different Types of SOAP nodes
involved with processing a message.

Figure 5.26: A message path consisting of three Web services.

Figure 5.27: A message path determined at runtime.

Soa chapter 5

Recommended

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Soa chapter 5 (20)

Recently uploaded (20)

Soa chapter 5