# Integration

> Integration styles (file transfer, shared database, RPC, messaging), enterprise integration patterns, message channels, routing, the web as connector, APIs.

## Integration styles and fundamentals

- [Connector Transparency (Direct vs Indirect Connection)](https://arc.fuet.ch/concepts/integration/connector-transparency.md): An indirect connector puts a channel between components, so a sender does not need to know who receives its data. This lowers coupling, but it makes the overall flow harder to follow.
- [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md): Enterprise Integration Patterns are named designs for connecting applications through messaging. Messaging is asynchronous, program-to-program communication with reliable delivery. Apache Camel supports most of these patterns.
- [File Transfer](https://arc.fuet.ch/concepts/integration/file-transfer.md): File Transfer is an integration style where each application writes files of shared data and reads files that others wrote. Teams must agree on the file format and how often files are produced.
- [Integration](https://arc.fuet.ch/concepts/integration/integration.md): Integration makes separate applications work together to deliver one unified set of functionality. Teams choose a style, keep dependencies low, and often add a translation layer where systems differ.
- [Integration Pattern vs. Middleware Technology](https://arc.fuet.ch/concepts/integration/integration-patterns-vs-middleware-technology.md): An integration pattern describes a solution without tying it to any product. Middleware is the concrete product or protocol that carries it out. Keeping the two apart lets you ask separate questions about each.
- [Integration Style](https://arc.fuet.ch/concepts/integration/integration-pattern.md): An integration style is the basic way separate applications are connected so they can share data and behavior. The classic options are file transfer, shared database, remote procedure call and messaging. Teams choose one deliberately.
- [Integration Styles](https://arc.fuet.ch/concepts/integration/integration-styles-overview.md): Applications can be connected in four basic ways: exchanging files, sharing a database, calling each other's procedures remotely, or sending messages. Each style has its own strengths and weaknesses, so you choose per integration point.
- [Patterns for API Design](https://arc.fuet.ch/concepts/integration/patterns-for-api-design.md): Patterns for API Design is a pattern language for remote APIs. It sorts patterns into five categories and treats each choice as a decision with options and criteria. Its focus is the messages that APIs exchange.
- [Principles Influencing EAI Pattern Selection](https://arc.fuet.ch/concepts/integration/principles-influencing-eai-pattern-selection.md): Pick an integration style by asking how tightly it ties applications together. Prefer styles that keep mutual dependencies low, so one application can change without breaking the others.
- [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md): Remote Procedure Call lets one application run a procedure in another application across a network. It looks like a local call but behaves differently: it is slower, can fail, and needs careful interface design.
- [Shared Database](https://arc.fuet.ch/concepts/integration/shared-database.md): A shared database lets several applications exchange data by storing it in one common database. Information is shared quickly and consistently. The price is deep coupling to one schema, which is hard to design and risky to change.
- [Software Connector Classification](https://arc.fuet.ch/concepts/integration/classification-of-integration-patterns.md): Connector classification compares integration styles on shared questions, such as synchronous or asynchronous and one-to-one or one-to-many. The answers show how each style behaves when a side is down or an interface changes.
- [Stream Connector](https://arc.fuet.ch/concepts/integration/stream.md): A stream connector passes data from one step to the next while the data flows. Buffers absorb speed differences between sender and receiver. Pipes and filters use it to build processing chains.
- [Synchronous vs Asynchronous Connector](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-connector.md): A synchronous connector needs sender and receiver to be up at the same time. An asynchronous connector, such as a queue, lets them work at different times, which limits how failures spread.
- [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md): A synchronous call makes the caller wait for the answer. An asynchronous call lets the caller move on. The choice shapes how failures spread and how replies are matched to requests.

## Messaging and channels

- [Datatype Channel](https://arc.fuet.ch/concepts/integration/datatype-channel.md): A Datatype Channel gives each type of data its own message channel. The sender picks the channel that matches the data. The receiver knows the type from the channel it reads.
- [Dead Letter Channel](https://arc.fuet.ch/concepts/integration/dead-letter-channel.md): A Dead Letter Channel is a side queue for messages a messaging system cannot deliver or process. Failed messages wait there to be inspected, fixed and resubmitted instead of being lost.
- [Event Sourcing with Distributed Event Log](https://arc.fuet.ch/concepts/integration/event-sourcing-with-distributed-event-log.md): A distributed event log is a shared, append-only record of events that many applications use to exchange data. Writers add events. Readers pull them at their own pace and can replay older events until retention removes them.
- [Invalid Message Channel](https://arc.fuet.ch/concepts/integration/invalid-message-channel.md): An Invalid Message Channel is a dedicated channel where a receiver puts messages it cannot process. The receiver handles bad messages gracefully, and people can inspect them later.
- [Message Channel](https://arc.fuet.ch/concepts/integration/message-channel.md): A message channel is a pipe between applications. One application writes messages into it, and another reads them out. The sender does not need to know the receiver. Channel types cover delivery, message types, errors, and durability.
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md): Messaging connects applications through a shared messaging system. Applications exchange small messages instead of calling each other directly, and sender and receiver need not be running at the same time.
- [Messaging Protocol Support in Message Brokers](https://arc.fuet.ch/concepts/integration/messaging-systems-and-protocols.md): Message brokers speak different wire protocols, the formats clients use to talk to them. Some brokers support several protocols natively or through plugins. Protocol support decides which clients can connect.
- [Point-to-Point Channel](https://arc.fuet.ch/concepts/integration/point-to-point-channel.md): A Point-to-Point Channel makes sure only one receiver gets each message. If several receivers share the channel, they compete, and each message goes to just one of them.
- [Publish/Subscribe Channel](https://arc.fuet.ch/concepts/integration/publish-subscribe-channel.md): A publish-subscribe channel gives every interested subscriber its own copy of each message. The sender does not know who the receivers are, so senders and receivers stay decoupled.

## Message construction

- [Claim Check](https://arc.fuet.ch/concepts/integration/claim-check.md): Claim Check keeps large data out of messages. The sender stores the data in an external store and sends only a small reference. The receiver uses that reference to fetch the data.
- [Correlation Identifier](https://arc.fuet.ch/concepts/integration/correlation-identifier.md): A Correlation Identifier lets a requester match a reply to the request that caused it. The replier copies the request's unique ID into a correlation ID field of the reply.
- [Format Indicator](https://arc.fuet.ch/concepts/integration/format-identifier.md): A Format Indicator is a tag on each message that names its data format. It helps a message format cope with future change, and it is an alternative to giving every data type its own channel.
- [Message Sequence](https://arc.fuet.ch/concepts/integration/message-sequence.md): Message Sequence splits data that is too big for one message into several smaller messages. Each message carries a position, so the receiver can put the parts back in order and rebuild the whole.
- [Message Structure](https://arc.fuet.ch/concepts/integration/message-structure.md): A message has a body that carries the data and a header that carries information for the messaging system. Header fields such as a correlation ID and a return address let a reply find its way back to the right request.
- [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md): Request-Reply lets a requestor send a message on one channel and get the answer on another. A correlation ID or a return address tells the requestor which reply belongs to which request.
- [Return Address](https://arc.fuet.ch/concepts/integration/return-address.md): A Return Address is a reply destination carried inside the request message. The replier reads it and sends the answer there, so it never needs to know in advance who is asking.

## Message routing

- [Composed Message Processor](https://arc.fuet.ch/concepts/integration/composite-message-processor.md): A Composed Message Processor keeps the overall message flow intact when one message holds several elements that may need different processing. An Aggregator gathers the results and decides when the combined answer is ready.
- [Content-based Router](https://arc.fuet.ch/concepts/integration/content-based-router.md): A Content-Based Router reads each message and sends it to a channel chosen from data inside the message. It lets one logical function span several systems. Its fixed rules need careful upkeep.
- [Dynamic Router](https://arc.fuet.ch/concepts/integration/dynamic-router.md): A Dynamic Router sends messages to recipients using rules it learns at runtime. Recipients tell the router what they want over a control channel, so the router needs no fixed list of destinations.
- [Message Filter](https://arc.fuet.ch/concepts/integration/message-filter.md): A Message Filter checks each message against a condition on its content. Matching messages move on and the rest are discarded, so a component avoids receiving messages it does not care about.
- [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md): Message routing patterns decide where each message goes, so a sender does not need to know the final recipient. Examples are the Content-Based Router, Recipient List, Aggregator, Scatter-Gather and Routing Slip.
- [Process Manager](https://arc.fuet.ch/concepts/integration/process-manager.md): A Process Manager is a central component that tracks the state of a process and decides the next processing step. It fits cases where the needed steps are not known in advance.
- [Recipient List](https://arc.fuet.ch/concepts/integration/recipient-list.md): Recipient List is a routing pattern for sending one message to a list of recipients that is decided dynamically. Apache Camel offers it, and Scatter-Gather can use it to send requests.
- [Routing Slip](https://arc.fuet.ch/concepts/integration/routing-slip.md): A Routing Slip is a list attached to a message that names the processing steps it must visit, in order. Each step reads the slip and passes the message on, so every message can follow its own path.
- [Scatter/Gather](https://arc.fuet.ch/concepts/integration/scatter-gather.md): Scatter-Gather sends one request to several recipients, then combines their replies into a single answer. The caller sees one response instead of many.

## Message transformation

- [Canonical Data Model](https://arc.fuet.ch/concepts/integration/canonical-data-model.md): A Canonical Data Model is one shared, application-independent data format that systems translate to and from. It cuts translation paths from n×n to n, but it is overkill for small integrations.
- [Content Enricher and Content Filter](https://arc.fuet.ch/concepts/integration/content-enricher.md): A Content Enricher adds data that a receiver needs but the sender lacks. A Content Filter does the opposite and removes data the receiver does not need. Both reshape messages to fit the receiver.
- [Content Filter](https://arc.fuet.ch/concepts/integration/content-filter.md): A Content Filter removes unimportant data items from inside a message and keeps only the important ones. It helps when a message is large and the receiver needs just a few items.
- [Envelope Wrapper](https://arc.fuet.ch/concepts/integration/envelope-wrapper.md): An Envelope Wrapper puts application data inside an envelope that the messaging system accepts. The receiver removes the envelope at the destination and gets the original data back.
- [Message Translator](https://arc.fuet.ch/concepts/integration/message-translator.md): A Message Translator is a special filter that converts messages from one data format to another. It lets systems with different formats communicate through messaging.
- [Normalizer](https://arc.fuet.ch/concepts/integration/normalizer.md): A Normalizer handles messages that mean the same thing but arrive in different formats. A router sends each message to a matching translator, so later steps deal with only one format.

## Messaging endpoints

- [Event-Driven Consumer](https://arc.fuet.ch/concepts/integration/event-driven-consumer.md): An Event-Driven Consumer waits until the messaging system hands it a message through a callback. It runs no polling loop. Arrivals set its pace, so a burst can overload it.
- [Idempotent Receiver](https://arc.fuet.ch/concepts/integration/idempotent-receiver.md): An idempotent receiver handles the same message more than once without repeating its effect. A common way is to record the IDs of processed messages and ignore any repeat.
- [Polling Consumer](https://arc.fuet.ch/concepts/integration/polling-consumer.md): A Polling Consumer asks a channel for the next message when it is ready, instead of waiting to be handed one. The consumer starts every retrieval, so it decides when to take work.
- [Selective Consumer](https://arc.fuet.ch/concepts/integration/selective-consumer.md): A Selective Consumer tells its channel which messages it wants. The channel delivers only matching messages, so the consumer does not have to sort through the rest itself.
- [Timeout-based Delivery](https://arc.fuet.ch/concepts/integration/timeout-based-delivery.md): Timeout-based delivery hides a message from other consumers while one consumer works on it. The consumer deletes it when done. If the timeout runs out first, the message reappears and is delivered again, so duplicates are possible.
- [Transactional Client](https://arc.fuet.ch/concepts/integration/transactional-client.md): A transactional client groups its message operations into one transaction. A sent message only enters the channel once the sender commits. The cost is slower performance in widely distributed systems.