Database Reference
In-Depth Information
The need for persistence patterns
To paraphrase what's written in
http://en.wikipedia.org/wiki/Service_oriented_architecture
,
the idea behind
Service-oriented Architecture
(
SOA
) is to decouple the end-to-end ap-
plication functionality between discreet services.
So far, we have discussed sagas and some metadata of applications. There are other types
of data that are saved to the data store, including business objects that contain the informa-
tion used for business rules. Business rules run the business engines and are used to execute
business logic.
In the ESB world, the bus transports (moves) objects that could be considered business ob-
jects; these business objects move through sagas. These objects are the pieces of NSBs that
are used for notifications, timeouts, gateways for message distribution,
Second-level
Retries
(
SLRs
), and even endpoints to where the messages are sent.
The preceding objects make up many of the application metadata. Many of these are the
configurations of the services that make up the distribution of the messages and the behavi-
or of the transactions. The metadata that NSB keeps track of during a publish-subscribe
message pattern is the same subscription information required for NSB to keep track of the
publish-subscribe endpoints. The subscription information is needed for the subscribers to
keep track of the message types and queue endpoints. This is needed to subscribe to the
publishers. NSB uses the database to keep track of these types of endpoints.
A small table of what is available can be seen at
http://docs.particular.net/nservicebus/
The persistence configurations are just some of the typical ESB service configurations in
NSB. There are many more configurations as NSB is meant to do so much more as a com-
plete automation framework for the middleware. We will be discussing the various features
and their associated configurations on the bus called IBus throughout this topic.
