Web Services and Primitive SOA

1
 The Web Services Framework
• What is Framework?
– A collection of things

• Web Services framework includes:

– Web Services
– Communication Agreement
– Messaging Framework
– Extensions of Second Generation

A technology framework is a collection of things. It can include one or more

architectures, technologies, concepts, models, and even sub-frameworks. The
framework established by Web services is comprised of all of these parts.

2
 Service as Web Service in SOA
• A service can be a web service in SOA if

– It ensures basic service orientation

– It implements a business functionality

3
 Classification of Web Services
• Temporary classification:
– Based on the roles it assumes during the runtime
processing of a message
– Also called Role based classification

• Permanent classification:
– Based on the application logic it provides and the
roles it assumes within a solution environment
– Also called Model based classification

We explore both of these design classifications in the following two sections:

service roles (temporary classifications)
service models (permanent classifications)

4
 Service roles (Temporary Classification)

• A web service can assume different roles depending

upon the context

• It can be
– Initiator
– Relayer
– Recipient

• A service can change role based on context

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.
It is not uncommon for a Web service to change its role more than once within a
given business task. It is especially not uncommon for a Web service within an SOA to
assume different roles in different business tasks.

5
 Service roles – Service Provider

The service provider role is assumed by a Web service under the following conditions:
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.

6
 Service roles – Service Provider
• Provider Role requires following conditions to be
fulfilled:
1. The Web service is invoked via an external
source, such as a service requestor.
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.

The service provider role is assumed by a Web service under the following conditions:
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. Depending on the type of message exchange used when invoking
a service provider, the service provider may reply to a request message with a
response message. (Types of message exchanges are categorized as "message
exchange patterns," which are explained in the next chapter.)

7
 Service Provider: Additional Terms
• 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

The term "service provider" also is used to identify the organization (or individual)
responsible for actually providing the Web service. To help distinguish the service role
from the service's actual provider, the following, more qualified terms are sometimes
used:
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)
It is, however, most common to simply refer to the service being invoked as the
service provider.

8
 Service roles – 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 (Figure 5.3).
The Web service searches for and assesses the most suitable service provider by
studying available service descriptions.

9
 Service roles – Service Requestor
• Requestor Role requires following conditions to be
fulfilled:
– 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.

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 (Figure 5.3).
The Web service searches for and assesses the most suitable service provider by
studying available service descriptions.
The service requestor is the natural counterpart to the service provider, comparable
to the client in a typical client-server environment. It is important to note that a
service provider is not acting as a service requestor when it sends a message in
response to a request message. A service requestor is best viewed as a software
program that initiates a conversation with a service provider.

10
 Service Requestor: Additional Terms
• 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

As with "service provider," this term is subject to some ambiguity. A service requestor
can represent both the Web service itself as well as the Web service owner.
Therefore, the following extended terms are available (but not really used that often):
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)
Another term frequently used instead of service requestor is service consumer.

11
In the first scenario, TLS acts as the service requestor entity. Its Purchase Order
Service was the service requestor (or service requestor agent) that initiated the
interaction. Being the recipient of the order request, the Order Fulfillment Service is
classified as the service provider (or service provider agent). As the owner of this
Web service, RailCo is the service provider entity.
The roles are reversed in the second scenario, where RailCo is the service requestor
entity because its Invoice Submission Service acts as the service requestor. TLS's
Accounts Payable Service receives the invoice message, making that Web service the
service provider, and TLS the service provider entity.

12
 Intermediaries
• Web services contrasts the predictable nature of
traditional point-to-point communications channels.
• Point to point: less flexible, less scalable but easier to
design
• SOA relies on Messaging paths - point-to-*

• “Web services and Agents that route and process a

message after it is sent and before it arrives”

The communications framework established by Web services contrasts the

predictable nature of traditional point-to-point communications channels. Though
less flexible and less scalable, point-to-point communication was a great deal easier
to design. Web services communication is based on the use of messaging paths,
which can best be described as point-to-* paths. This is because once a service
provider submits a message, it can be processed by multiple intermediate routing and
processing agents before it arrives at its ultimate destination.

13
Web services and service agents that route and process a message after it is initially
sent and before it arrives at its ultimate destination are referred to as intermediaries
or intermediary services. Because an intermediary receives and submits messages, it
always transitions through service provider and service requestor roles

14
 Types of Intermediaries
• Passive Intermediary:
– Routes a message to subsequent location
– Does not modify the message (SOAP Header)

• Active Intermediary:
– Routes, processes and alters the message
contents
– Can add/remove SOAP headers

15
There are two types of intermediaries. The first, known as a passive intermediary, is
typically responsible for routing messages to a subsequent location (Figure 5.6). It
may use information in the SOAP message header to determine the routing path, or it
may employ native routing logic to achieve some level of load balancing. Either way,
what makes this type of intermediary passive is that it does not modify the message.

16
Like passive intermediary services, active intermediaries also route messages to a
forwarding destination. Prior to transmitting a message, however, these services
actively process and alter the message contents (Figure 5.7). Typically, active
intermediaries will look for particular SOAP header blocks and perform some action
in response to the information they find there. They almost always alter data in
header blocks and may insert or even delete header blocks entirely

17
 Initial Sender And Ultimate Receiver
• Initial Sender:
– Requestor that initiates the transmission of a
message

• Ultimate Receiver:
– Provider that exists as the last web service on the
message path

18
Initial sender and ultimate receiver
Initial senders are simply service requestors that initiate the transmission of a
message. Therefore, the initial sender is always the first Web service in a message
path. The counterpart to this role is the ultimate receiver. This label identifies service
providers that exist as the last Web service along a message's path

19
 Can intermediary services ever be
initial senders or ultimate receivers
within the scope of a service activity?

Note that intermediary services can never be initial senders or ultimate receivers
within the scope of a service activity.

20
Expanding on the previous example that demonstrated the use of a passive
intermediary, let's take a look at all the services involved in that message exchange. In
this scenario, we had the RailCo Invoice Submission Service (acting as the service
requestor) initiating the message transmission. By receiving the message, the Load
Balancing intermediary acts as the service provider. Upon routing the message, the
intermediary temporarily assumes the service requestor role and sends the message
to the Accounts Payable Service, another service provider (Figure 5.9).
Figure 5.9. The TLS Load Balancing Service acting as an intermediary between the
RailCo initial sender and the TLS ultimate receiver.
These three physical services created four logical roles to complete two service
requestor-to-service provider transmissions. There was, however, only one Web
service that initiated the transmission. This was the Invoice Submission Service, and it
is therefore considered the initial sender. Similarly, there was only one Web service
that ended the overall activity, which makes the Accounts Payable Service the
ultimate receiver.

21
 Service Compositions

A service composition consisting of four members.

As the name suggests, this particular term does not apply to a single Web service, but
to a composite relationship between a collection of services. Any service can enlist
one or more additional services to complete a given task. Further, any of the enlisted
services can call other services to complete a given sub-task. Therefore, each service
that participates in a composition assumes an individual role of service composition
member (Figure 5.10).
Typically, Web services need to be designed with service composition in mind to be
effective composition members. Service-orientation principles place an emphasis on
composability, allowing some Web services to be designed in such a manner that
they can be pulled into future service compositions without a foreknowledge of how
they will be utilized.
Service compositions also are referred to as service assemblies.

22
When the TLS Accounts Payable Service receives an invoice, it invokes a series of
additional services to fully process the invoice contents:
It first uses the Vendor Profile Service to validate the invoice header data and link the
invoice document to a vendor account.
Next, the Accounts Payable Service extracts taxes and shipping fees and directly logs
all amounts into the appropriate A/P accounts.
Finally, the Accounts Payable Service passes the Ledger Service the invoice total,
which it uses to update the General Ledger.
In this scenario our service composition consists of three composition members,
spearheaded by the Accounts Payable Service (Figure 5.11).
Figure 5.11. The Accounts Payable Service enlisting other TLS services in a service
composition.
A characteristic of this particular composition that is not discussed here is the fact
that all three actions we described would very likely be wrapped in a transaction.
Should one of them fail, all others would be rolled back.

23
 Service Models
• Services can be classified based on the nature of the
application logic

– These classifications are known as service models.

• Business service
• Controller service
• Utility service, etc...

The roles we've explored so far are agnostic to the nature of the functionality being
provided by the Web service. They are generic states that a service can enter within a
generic context. 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.

24
 Business Service Model
• Within an SOA, the business service represents the
most fundamental building block.

• It is fully autonomous but still not limited to

executing in isolation,
– as business services are frequently expected to
participate in service compositions.

It encapsulates a distinct set of business logic within a well-defined functional

boundary.

25
 Business Service Model
• Business services are used within SOAs as follows:

– to represent business process logic

– as service composition members

26
 Utility Service Model
• A service that offers reusable logic.

• This category is primarily intended for the

classification of solution-agnostic application service.

Any generic Web service or service agent designed for potential reuse can be
classified as a utility service. The key to achieving this classification is that the
reusable functionality be completely generic and non-application specific in nature.

27
 Utility Service Model
• 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

28
 Classify the Following
• Accounts Payable Service
• Internal Policy Service
• Invoice Submission Service
• Ledger Service
• Load Balancing Service
• Order Fulfillment Service
• Purchase Order Service
• Vendor Profile Service

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:…
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.

29
 Controller Service Model
• A service that composes others.

• 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

• Master controller and sub-controller

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.
Variation of this model exist, depending on the position of the controller in the
composition hierarchy. The parent controller service can be classified as the master
controller and a service that composes a subset of a larger composition can be
labelled as a sub-controller.

30
Figure 5.12. A service composition consisting of a master controller, a sub-controller,
four business services, and one utility service.
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).

31
Figure 5.13. The Accounts Payable Service acting as a business and controller service,
composing two other business services.
In our previous example we demonstrated how the Accounts Payable Service initiated
and coordinated a service composition consisting of two additional composition
members. That would classify the Accounts Payable Service as a controller service.
The fact that we already labeled this service as a business service does not conflict
with this new classification; a single service can be classified as more than one
service model (Figure 5.13).

32
 Service roles and Service models
• Web services can be labeled using temporary and
permanent classifications.
• Temporary classifications relate to roles assumed by a
service at runtime.
– For example, an intermediary service can transition
through different roles while processing a message.
• Service models refer to permanent classifications that
represent the logic housed by the service, as well as its
role within the overall solution.
– “A service can belong to more than one service
model.”

33
 Service Descriptions (with WSDL)
• What is the importance of service descriptions?

– Descriptions are needed to ensure loose coupling

among services.
– Description documents are required to
accompany any service wanting to act as an
ultimate receiver.

When we covered loose coupling in Chapter 3 as part of our primitive SOA discussion,
we introduced the essential need for service descriptions. 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).

34
WSDL definitions enable loose coupling between services

35
Figure 5.15. Each service requestor is using the WSDL of a service provider to ensure
that messages sent will be understood and accepted.
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.)

36
 What is Legacy system adapter?

It is my personal opinion that any time a Service Component needs to interface to a

legacy system, that an Adapter Pattern should be used. This Adapter performs a
number of tasks. Its primary function is to convert to/from data formats spoken by
the legacy system and the common data formats used by the Foundational Service
Components. In order to perform the conversions, it may be necessary for an adapter
to interface with many Service Components in order to perform data enrichment or
break data apart into its fundamental data types.

37
 What is WSDL?

SOA services have self-describing interfaces in platform-independent XML

documents. Web Services Description Language (WSDL) is the standard used to
describe the services.

38
 What is UDDI?

SOA services are maintained in the enterprise by a registry that acts as a directory
listing. Applications can look up the services in the registry and invoke the service.
Universal Description, Discovery, and Integration (UDDI) is the standard used for
service registry.

39
 What is QoS of service?

Each SOA service has a quality of service (QoS) associated with it. Some of the key
QoS elements are security requirements, such as authentication and authorization,
reliable messaging, and policies regarding who can invoke services

40
 Service endpoints and service
descriptions
• 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.

41
 WSDL Organization
• A WSDL service description can be separated into
two parts:

– Abstract description

– Concrete description

A WSDL service description (also known as WSDL service definition or just WSDL
definition)

42
Figure 5.16. WSDL document consisting of abstract and concrete parts that
collectively describe a service endpoint.
Figure 5.16 shows how these individual descriptions comprise a WSDL definition.
Note the logical hierarchy established within the parts of the abstract definition. We
will explain each of these parts shortly.
The term "portType" is being renamed to "interface" in version 2.0 of the WSDL
specification.

43
 Abstract description
• “An abstract description establishes the interface
characteristics of the Web service”
– without any reference to the technology used to
host the web service

• Consists of three elements:

– portType
• Operation
–Message

By separating this information, the integrity of the service description can be

preserved regardless of what changes might occur to the underlying technology
platform.

44
 Abstract description
• portType:

– The portType section of an abstract description

provides a high-level view of the service interface

– “Sorts the messages a service can process into

groups of functions, known as operations.”

45
 Abstract description
• Operation:
– “Each operation represents a specific action
performed by the service.”
– A service operation is comparable to a public
method used by components in traditional
distributed applications.
– Much like component methods, operations also
have input and output parameters.

46
 Abstract description
• Message:
– 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 TLS Accounts Payable Service was created to receive invoices submitted by
numerous vendors. Its associated service description therefore has a simple abstract
description consisting of one interface definition that contains a single operation
called SubmitInvoice.
Specified within the operation is one input and one output message. The input
message is responsible for accepting the invoice document from a vendor service
requestor (such as the RailCo Invoice Submission Service). The output message is
used by the Accounts Payable Service to send a message of acknowledgement
indicating that the submitted invoice document has been successfully received and
that its contents are valid. The concrete part of this service description simply binds
the operation to the SOAP protocol and provides a location address for the Accounts
Payable Service.

47
 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.

– This connection is defined in the concrete

description portion of the WSDL

48
WSDL file, which consists of three related parts:
binding, port, and service

49
 Concrete description
• Binding:
– A WSDL description's binding describes the
requirements for
• a service to establish physical connections with
this 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.

50
 Concrete description
• Port:
– It represents the physical address at which a
service can be accessed with a specific protocol.

• Service:
– Within the WSDL language, the term service is
used to refer to a group of related endpoints.

The term "port" is being renamed "endpoint" in version 2.0 of the WSDL
specification. The WSDL endpoint should not be confused with the general term
"endpoint" used to reference the point of contact for a Web service. Though related,
the term "endpoint" is used in a much broader sense than the WSDL endpoint, which
refers to a language element that only represents the physical address of the service.

51
 Example
• For the Abstract Description, Accounts Service
supports following operation:
– SubmitInvoice
• This operation contains following messages:
– AcceptInvoice (Input Message)
– SendAck (Output Message)

• Concrete description for the service binds above

mentioned operation to SOAP and also provides the
address of accounts service.

52
53
 Metadata and Service Contract
• Service Metadata
– WSDL definition
– XSD schema
– Policy

• Service Contract
– Above Three + Legal Documents

So now 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 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).

54
A service contract comprised of a collection of service descriptions and possibly
additional documents.

55
 Semantic Description
• Service's behavioral characteristics

• 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

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.
Most of the time service semantics are assessed by humans, either verbally by
discussing the qualities of a service with its owner, or by reading supplementary
documentation published alongside service descriptions. The ultimate goal is to
provide sufficient semantic information in a structured manner so that, in some
cases, service requestors can go as far as to evaluate and choose suitable service
providers independently.
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.

56
 Message Exchange Patterns
• Web service tasks are considered different based on
the application logic and role played by the service.
– Tasks are executed by the transmission of multiple
messages
• Coordination is important

• Do all message exchanges require both requests and

responses?

Every task automated by a Web service can differ in both the nature of the
application logic being executed and the role played by the service in the overall
execution of the business task. Regardless of how complex a task is, almost all require
the transmission of multiple messages. The challenge lies in coordinating these
messages in a particular sequence so that the individual actions performed by the
message are executed properly and in alignment with the overall business task

57
 “Message exchange patterns (MEPs) represent a set of
templates that provide a group of already mapped out
sequences for the exchange of messages.”
1. Primitive MEPs
2. Complex MEPs

Figure 6.2. Not all message exchanges require both requests and responses.
Message exchange patterns (MEPs) represent a set of templates that provide a group
of already mapped out sequences for the exchange of messages. The most common
example is a request and response pattern. Here the MEP states that upon successful
delivery of a message from one service to another, the receiving service responds
with a message back to the initial requestor.

58
 Primitive MEPs
• Request-response
– The one pattern that defines synchronous
communication

Before the arrival of contemporary SOA, messaging frameworks were already well
used by various messaging-oriented middleware products. As a result, a common set
of primitive MEPs has been in existence for some time.
Request-response
This is the most popular MEP in use among distributed application environments and
the one pattern that defines synchronous communication (although this pattern also
can be applied asynchronously).
The request-response MEP (Figure 6.3) establishes a simple exchange in which a
message is first transmitted from a source (service requestor) to a destination
(service provider). Upon receiving the message, the destination (service provider)
then responds with a message back to the source (service requestor).

59
Figure 6.4. A sample request-response exchange between the TLS Accounts Payable
and Vendor Profile Services.
In the Service compositions section of Chapter 5, we provided an example where the
TLS Accounts Payable Service, upon receiving an invoice submission from a vendor,
enlists the TLS Vendor Profile Service to validate the invoice header information.
The MEP used in this situation is the standard request-response pattern, where a
response from the Vendor Profile Service is expected once it receives and processes
the original request. The Accounts Payable Service requires a response to ensure that
the header details provided in the invoice submission are valid and current (Figure
6.4). Failure to validate this information terminates the Invoice Submission Process
and results in the Accounts Payable Service responding to the vendor with a rejection
message.

60
 Primitive MEPs
• Fire-and-forget
– This simple asynchronous pattern is based on the
unidirectional transmission of messages from a
source to one or more destinations

61
 Primitive MEPs
• Fire-and-forget Variations:
– The single-destination pattern, where a source
sends a message to one destination only.
– The multi-cast pattern, where a source sends
messages to a predefined set of destinations.
– The broadcast pattern, which is similar to the
multi-cast pattern, except that the message is sent
out to a broader range of recipient destinations.

A number of variations of the fire-and-forget MEP exist, including:

The single-destination pattern, where a source sends a message to one destination
only.
The multi-cast pattern, where a source sends messages to a predefined set of
destinations.
The broadcast pattern, which is similar to the multi-cast pattern, except that the
message is sent out to a broader range of recipient destinations.
The fundamental characteristic of the fire-and-forget pattern is that a response to a
transmitted message is not expected.

62
Figure 6.6. The TLS Accounts Payable Service sending off a one-way notification
message.
The TLS Accounts Payable Service contains a rule that when an invoice header fails
validation, an e-mail notification is generated. To execute this step, the Accounts
Payable Service sends a message to the Notification Service. This utility service
records the message details in a notification log database. (These records are used as
the basis for e-mail notifications, as explained in the next example.) Because the
message sent from the Accounts Payable Service to the Notification Service requires
no response, it uses a single-destination fire-and-forget MEP (Figure 6.6).

63
 Complex MEPs
• Primitive MEPs can be assembled in various
configurations to create different types of messaging
models, sometimes called complex MEPs.

• A classic example is the publish-and-subscribe

model.

Even though a message exchange pattern can facilitate the execution of a simple task,
it is really more of a building block intended for composition into larger patterns.
Primitive MEPs can be assembled in various configurations to create different types
of messaging models, sometimes called complex MEPs.

64
 Complex MEPs
• The publish-and-subscribe pattern
– It introduces new roles for the services involved
with the message exchange.
• Publishers and subscribers
– This asynchronous MEP accommodates a
requirement for a publisher to make its messages
available to a number of subscribers interested in
receiving them.

The publish-and-subscribe pattern introduces new roles for the services involved with
the message exchange. They now become publishers and subscribers, and each may
be involved in the transmission and receipt of messages. This asynchronous MEP
accommodates a requirement for a publisher to make its messages available to a
number of subscribers interested in receiving them.

65
 Complex MEPs
• The publish-and-subscribe pattern
– Step 1.
The subscriber sends a message to notify the
publisher that it wants to receive messages on a
particular topic.
– Step 2.
Upon the availability of the requested
information, the publisher broadcasts messages
on the particular topic to all of that topic's
subscribers.

The steps involved are generally similar to the following:

Step 1.
The subscriber sends a message to notify the publisher that it wants to receive
messages on a particular topic.
Step 2.
Upon the availability of the requested information, the publisher broadcasts
messages on the particular topic to all of that topic's subscribers.

66
This pattern is a great example of how to aggregate primitive MEPs, as shown in
Figure 6.7 and explained here:
Step 1 in the publish-and-subscribe MEP could be implemented by a request-
response MEP, where the subscriber's request message, indicating that it wants to
subscribe to a topic, is responded to by a message from the publisher, confirming that
the subscription succeeded or failed.
Step 2 then could be supported by one of the fire-and-forget patterns, allowing the
publisher to broadcast a series of unidirectional messages to subscribers.
Figure 6.7. The publish-and-subscribe messaging model is a composite of two
primitive MEPs.
WS-* specifications that incorporate this messaging model include:
WS-BaseNotification
WS-BrokeredNotification
WS-Topics
WS-Eventing
Concepts relating to these specifications are discussed in the next chapter as part of
the Notification and eventing section.

67