IT-312 – Systems Integration and Architecture Midterm Examination Reviewer

A comprehensive vocabulary review set covering architectural patterns, system models, integration approaches, and API and middleware concepts for IT-312.

Service-Oriented Architecture (SOA)

An architecture that organizes functionality as services with defined interfaces, placing an emphasis on reusability so that services can be accessed by other parts of a system when needed.

Layered Architecture

An architecture in which a system is organized into hierarchical layers, each with a defined responsibility, making the structure easier to understand and maintain.

Repository Architecture

An architecture where components access a shared, central repository for data to support data sharing, though components may become dependent on the central store.

Client–Server Architecture

An architecture where clients request data or services while servers process requests and provide responses, dividing responsibilities between the two sides.

Pipe-and-Filter Architecture

An architecture where data passes through a sequence of independent filters connected by pipes, with each filter performing a processing step before passing its output onward.

Event-Driven Architecture

An architecture where components produce and respond to events to trigger actions or communicate occurrences, reducing the need for components to directly call one another for every interaction.

Microservices Architecture

An architecture where an application is divided into relatively independent services that can be developed, deployed, and scaled separately, improving flexibility while introducing service-communication and maintenance considerations.

Model–View–Controller (MVC)

A pattern that separates responsibilities among the Model, View, and Controller to keep application data, presentation, and input-handling logic organized.

Architectural Patterns

Design concepts that provide reusable guidance for recurring system-design problems, chosen based on a system's needs and the trade-offs involved.

Context Model

A system model that gives an overview of the system boundary and the external people, organizations, or systems that interact with it, clarifying what belongs inside and outside the system.

Data Flow Model

A system model representing how information moves through processes, data stores, and external entities, useful for examining inputs, transformations, storage, and outputs.

Class Model

A system model that represents the static structure of a system through classes, attributes, methods, and relationships to describe object-oriented software organization.

Activity Model

A system model that represents actions and the flow of work within a process, helping explain the steps and possible paths in a workflow.

Sequence Model

A system model that shows messages exchanged between objects or components in time order, emphasizing the order of interactions rather than changing states.

State Machine Model

A system model that represents the states an object can occupy and the events that cause transitions between them, used when behavior changes according to events or conditions.

Deployment Model

A system model that shows where software artifacts are placed on hardware nodes or runtime environments, focusing on physical or execution arrangements.

Component Model

A system model describing software components and how they are organized or interact through interfaces, providing a view of the system's software building blocks.

Entity-Relationship (ER) Model

A system model representing data entities, their attributes, and relationships between them, commonly used to plan or communicate a data structure.

System Models

Analytical abstractions chosen to match specific questions being addressed, such as system boundaries, data movement, workflow, static structure, messages, states, or deployment.

Top-Down Integration

An integration approach that begins with the high-level architecture and then addresses subsystems and details, supporting design alignment but requiring upfront planning that can be rigid.

Bottom-Up Integration

An integration approach that starts with individual components or subsystems, tests them, and combines them gradually to reveal component-level issues early.

Middleware-Based Integration

An integration approach where middleware acts as an intermediary to help systems communicate and transform data formats or protocols, offering centralized management at the cost of added complexity.

API-Based Integration

An integration approach where systems communicate through defined API endpoints and service interfaces, supporting standardized access to services and data.

Selecting an Integration Strategy

The decision-making process based on how existing systems are structured and communicate, differences in technologies or data formats, and the need for centralized monitoring or architectural alignment.

Application Programming Interface (API)

A definition of how one software component can request data or functionality from another, allowing systems to communicate through agreed interfaces.

REST

An architectural approach used to design web APIs around resources and standardized web interactions, commonly used by web and mobile applications to access services.

API Gateway

A centralized entry point for requests to APIs that can route requests and apply shared policies, though it does not automatically eliminate security risks.

OAuth

An authorization framework used to grant limited access to resources, requiring appropriate security configuration and access controls.

API Security

The application of suitable authentication and authorization controls to protect services and data exposed by APIs.

Middleware

Software that helps separate applications or systems communicate by managing messages, coordinating interactions, or transforming data depending on its type.

Message Broker

A component that receives and routes messages between applications or services, helping to decouple senders from receivers.

Message-Oriented Middleware (MOM)

Middleware that supports communication through messages, including asynchronous messaging where the sender and receiver do not need to process a message at the same time.

Asynchronous Messaging

A messaging capability supported by MOM where the sender and receiver do not necessarily need to process a message at the same time.

Filter

An independent processing component in a pipe-and-filter architecture that performs a processing step before passing its output onward.

Pipe

A connector in a pipe-and-filter architecture that passes data onward between consecutive, independent processing filters.

Service

A modular unit of functionality with defined interfaces in an SOA, designed with an emphasis on reusability to be accessed by other system parts.

Client

A component in a client–server architecture that initiates requests for data or services from a server.

Server

A component in a client–server architecture responsible for processing incoming client requests and providing responses.

Software Artifacts

The software components or executables shown placed on hardware nodes or runtime environments within a deployment model.

Central Repository

A shared, centralized store for data accessed by components in a repository architecture to facilitate data sharing.