ITSA Cheatsheet
ITSA Cheatsheet
An
architectural description is organized into one or more constituents called (architectural) views. Each view addresses one or more of the
concerns of the system stakeholders. A view is a partial expression of a system's architecture with respect to a particular viewpoint .
Messaging
● Use cases: For record/transaction data, asynchronous update of information to backend applications,
sending notifications to customers, business to business transactions
● Can operate in synchronous or asynchronous communication
● Can be centralized or decentralized (similar to FTP)
● Need to define the file format, selectivity, persistence, durability, exception handling
● Basic messaging concepts: Channel- Messaging applications transmit data through a channel, Messages
- atomic packet of data, Routing - messaging router is an application that will determine how to navigate
the network topology, Transformation, Endpoints
● Messaging channel types:
○ Point to point (one to one)only one receiver consumes any particular message
○ Publish subscribe (one to many)
■ good debugging tool: Creating a program that listens for messages on all active channels and logs
them to a file can realize many of the same benefits that a Message Store brings.
○ Datatype channel: all data on a particular channel is of the same type
○ Dead letter queues
● Message bus
○ a combination of a common data model, a common command set, and a messaging infrastructure to
allow different systems to communicate through shared interfaces
○ command communication infrastructure e.g. message router, publish-subscribe channels
○ Adapter: for the different systems to interface with the message bus; may be done using custom or
commercial channel adapters and service activators that can handle things like invoking CICS
transactions with the proper parameters; requires a data model all services can agree on
○ common command structure e.g. command messages, datatype channels (where a message router
makes an explicit decision on how to route particular messages to particular endpoints)
● Messaging construction
○ request reply: two participants (requestor and replier), request can be point to point or publish
subscribe but reply is almost always point to point, when a caller performs a remote procedure
invocation, the caller’s thread must block while it waits for a response. requester has two approaches
for receiving a reply (synchronous block and asynchronous block)
○ Need: (Return address) so the replier knows where to send the reply to, Correlation ID so the
requester knows which request the reply is for
● Message routing: Message broker (comparable to pipes and filter architectural style, message broker may
become bottleneck → to alleviate this, can deploy multiple instances of the broker while ensuing the
communication channel between the publisher and the broker instances is point to point such that only
one instance of the broker consumes the message, Message broker hierarchy (for decoupling): “subnet
style” routing of messages - instead of routing directly to consumer applications, route to other brokers /
local message brokers can pass message to central message broker)
○ Process manager: Initialized by a trigger message, Follows the hub and spoke pattern, The process
manager is the hub and can execute a sequence of steps sequentially or in parallel, Process
manager may become a bottleneck, Many patterns of designing it based on workflow, business
process management
○ Content-based routing: Handles the case where implementation of a single logical function (e.g.
inventory check) is spread over several physical systems
○ Splitter and aggregator
● Message transformation
○ Canonical Data model: To minimize dependencies when integrating applications that use different
data formats, requires that application consumes and publishes messages in a certain format
● Messaging endpoint:
○ Polling consumer vs event driven consumer (Polling: Makes a request for a message when it is ready,
Event driven: Handles message when message is delivered)
○ Selective consumer: Selects messages that fit its criteria
○ Durable subscriber: In order to receive messages sent to it even if it isn’t up and running; Non durable
is less resource intensive; Durable vs persistent: If I am a durable subscriber, when I go down and
come back up again, I will be guaranteed to get the message while Persistence is about the message
itself