Messaging Metadata
How can services be designed to consume activity
state data at runtime?
|
Problem
Because messaging does not
rely on a persistent connection between service and consumer, it is
challenging for a service to gain access to the state data associated with an
overall runtime activity.
|
|
Solution
The message contents can be
supplemented with activity-specific metadata that can be interpreted and
processed separately at runtime.
|
|
Application
This pattern requires a
messaging framework that supports message headers or properties.
|
Impacts
The interpretation and
processing of messaging metadata at runtime increases the performance
overhead of messaging-based communication.
|
|
Principles
Service Loose Coupling,
Service Statelessness
|
Architecture
Composition
|
Table 6.14 – Profile summary for
the Messaging Metadata pattern.
Problem
Persistent binary connections between a service and its
consumer place various types of state and context data about the current
service activity into memory, allowing routines within service capabilities to
access this information as required.
Moving from RPC-based communication toward a messaging-based
framework removes this option, as persistent connections are no longer
available. This can place the burden of activity management onto the services
themselves.
Solution
State data, rules, and even processing instructions can be
located within the messages. This alleviates services from having to include
activity-specific logic and provides capabilities within state data at runtime.
Figure 6.65 – Messages equipped
with metadata reduce the requirements for services to contain embedded,
activity specific solution logic.
Application
Quite simply, the messaging technology used for service
communication needs to support message headers or properties so that the
messaging metadata can be consistently located within a reserved part of the
message document.
Platform-specific technologies, such as JMS, provide support
for message headers and properties, as do more agnostic frameworks, such as
SOAP. Many types of messaging metadata have been standardized through the
emergence of WS-* extensions that define industry standard SOAP header blocks,
as demonstrated by the variety of examples provided in the upcoming Case
Study Example section, as well as the case study examples in the
Message-Level Security, Reliable Messaging, and Cross-Service Transaction
pattern descriptions.
Figure 6.66 – Header blocks allow
for various types of metadata to accompany the message contents.
Impacts
Although overall memory consumption is lowered by avoiding a
persistent binary connection, performance demands are increased by the
requirement for services to interpret and process metadata at runtime. Agnostic
services especially can impose more runtime cycles, as they may need to be
outfitted with highly generic routines capable of interpreting and processing
different types of messaging headers so as to participate effectively in
multiple composition activities.
Relationships
The application of the Messaging Metadata pattern is a
natural part of Web services-based messaging, especially in relation to SOAP
headers. In this context, this pattern can be seen as an extension of the basic
Service Messaging pattern and therefore fundamental to Capability Recomposition
in messaging-based environments.
Web service compositions that rely on industry standard
transaction management, security, routing and reliable messaging will therefore
utilize specialized implementations of this pattern, namely Cross-Service
Transaction, Message-Level Security, Intermediate Routing, and Reliable
Messaging. The Stateful Services pattern may also require the application of
this pattern when state data needs to be represented as messaging metadata.
Figure 6.67 – The Messaging
Metadata pattern is commonly associated with SOAP message headers and their use
within key WS-* industry standards.
Case Study Example
Case study content is not available on this Web site.
