|
This section contains detailed models showing how
some of the features of SOA can be implemented
using the SOA Reference Architecture.
The building blocks shown in these models
fall into the categories described underThe Building Blocks of SOA, but are at a lower level of abstraction.
Some of them are described further under Infrastructure for SOA.
They are all building blocks of the SOA Reference Architecture.
 Composition
This is the basic model for service composition.
The composite service is created by putting together the element services.
This may simply be a matter of performing the element services one after another,
or there may be more complex interactions between the services that affect the order in which they are performed.
In this latter case, the performance of the services may be controlled by scripts.
The model for scripted service composition is shown below.
In this model, one or more of the element services is controlled by a script,
executed by a composition engine.
The script is written in a language (such as the Web Services Business Process Execution
Language [BPEL] defined by OASIS) that includes constructs for inter-acting with other services.
(This interaction is often via messages, and composition engines are often integrated with messaging
programs.)
In a common orchestration scenario, only one of the element services is controlled by a script.
This service directs the other services by invoking them in the appropriate sequence.
In a common choreography scenario, all of the element services are controlled by scripts,
and these scripts are written so as to synchronize the performance of the element services.
Messaging
This is the basic messaging model.
Programs can exchange messages using a messaging service that is performed by
a messaging program. One program submits a message to the messaging program,
which delivers the message to a second program.
The message is sent by the first program, and received by the second.
These programs are both consumers of the messaging service.
The consumer programs that send and receive the messages
can be programs that perform services.
In this case, we also say that the services are sending and receiving the messages.
Use of a single program for communication between services makes it easy to process
the information as it is exchanged, by adding other programs onto the messaging program.
Several SOA features, such as message monitoring and data translation,
are commonly implemented in this way.
A detailed messaging model, including several such programs,
is shown below.
The consumer programs are as in the Basic Messaging Model.
The management programs perform functions such as setting up and changing routing tables,
configuring the infrastructure building blocks that are attached to the bus,
and managing logs and audit trails.
The programs other than the consumer programs and the management programs
combine to perform the messaging service. They all realize infrastructure building blocks.
The programs shown in the Detailed Messaging Model above support a rich set of capabilities.
Not all of these capabilities are required for a viable messaging service,
and not all of these programs need be present.
Service Discovery
This is the model for service discovery.
A program (the consumer program) wishes to use a service.
It makes a discovery request to a program that performs a registry service,
specifying the characteristics of the service that it wishes to use.
The registry program replies with a discovery response,
giving descriptions of services that meet the specification (the consumable services).
The consumer program can then use one (or more) of the consumable services.
The consumer program can be a program that performs a service.
It is a consumer of the registry service,
and is also a consumer of whichever of the consumable services it uses.
Asset Wrapping
This is the model for asset wrapping.
The service component
in this model is a program that implements
one or more of the interfaces of a service and invokes existing assets
in order to deliver the required functionality.
It need not itself have much functionality, and is sometimes described as a façade.
The service is performed by its service components and the assets that they invoke.
Virtualization
This is the model for virtualization.
This model can be used to define the internal structure of a service component
in order to create a virtualized service.
The service interface program implements the interface that is used by consumers of the service,
in accordance with the service contract.
The asset interface programs invoke the underlying assets whose capabilities are exposed by the service.
The control and supply program invokes the underlying assets
via the asset interface programs,
using appropriate numbers of assets with regard to the level of demand
and the ability of currently-used assets to respond.
Details of available assets are held in the asset repository,
which is maintained as assets are commissioned and decommissioned to show which are in service.
The demand monitoring program monitors the level of demand for the service,
and the results monitoring program assesses the response.
Event Processing
This is the model for event processing.
The event processor
detects input events with associated information,
and generates output events with associated information.
A single output event may correspond to multiple input events,
and the information associated with an output event is derived from
all the information associated with the corresponding input events.
A common scenario is that the input events are messages on a message bus,
and the output events are handled by analysis and presentation programs within an activity monitor.
|
You are here:
