Term	Definition
Event handling	Event handling is the receipt of an identifiable occurrence at a designated receiver (“handler”). The key processes involved in event handling include: Identifying where to forward an event Executing that forwarding action Receiving a forwarded event Taking some kind of appropriate action in response, such as writing to a log, sending an error or recovery process, or sending an extra message Keep in mind that the event handler can ultimately forward the event to an event consumer. Common uses of this feature with middleware can be extended to include the popular “publish/subscribe” or “pub/sub” capability. In a publish/subscribe scenario, the middleware routes requests or messages to active data-event subscribers from active data-event publishers. These consumers with active listeners can then retrieve the events as they’re published. In Salesforce integrations using middleware, the middleware layer assumes control of event handling. It collects all relevant events, synchronous or asynchronous, and manages distribution to all endpoints, including Salesforce. Alternatively, this capability can be achieved with the Salesforce enterprise messaging platform by using the event bus with platform events. See http://searchsoa.techtarget.com/definition/event-handler.
Protocol conversion	Protocol conversion “is typically a software application that converts the standard or proprietary protocol of one device to the protocol suitable for another device to achieve interoperability. In the context of middleware, connectivity to a particular target system may be constrained by protocol. In such cases, the message format needs to be converted to or encapsulated within the format of the target system, where the payload can be extracted. This is also known as tunneling. ” ¹ Salesforce doesn’t support native protocol conversion, so it’s assumed that any such requirements are met by the middleware layer or the endpoint. See https://www.techopedia.com/definition/30653/protocol-conversion.
Translation and transformation	Transformation is the ability to map one data format to another to ensure interoperability between the various systems being integrated. Typically, the process entails reformatting messages en route to match the requirements of the sender or recipient. In more complex cases, one application can send a message in its own native format, and two or more other applications can each receive a copy of the message in their own native format. Middleware translation and transformation tools often include the ability to create service facades for legacy or other non-standard endpoints. These service facades allows those endpoints to appear to be service-addressable. With Salesforce integrations, it’s assumed that any such requirements are met by the middleware layer or the endpoint. Transformation of data can be coded in Apex, but we don’t recommend it due to maintenance and performance considerations. See http://en.wikipedia.org/wiki/Message-oriented_middleware.
Queuing and buffering	Queuing and buffering generally rely on asynchronous message passing, as opposed to a request-response architecture. In asynchronous systems, message queues provide temporary storage when the destination program is busy or connectivity is compromised. In addition, most asynchronous middleware systems provide persistent storage to back up the message queue. The key benefit of an asynchronous message process is that if the receiver application fails for any reason, the senders can continue unaffected. The sent messages simply accumulate in the message queue for later processing when the receiver restarts. Salesforce provides only explicit queuing capability in the form of workflow-based outbound messaging. To provide true message queueing for other integration scenarios, including orchestration, process choreography, and quality of service, a middleware solution is required. See http://en.wikipedia.org/wiki/Message-oriented_middleware.
Synchronous transport protocols	Synchronous transport protocols refer to protocols that support activities wherein a “single thread in the caller sends the request message, blocks to wait for the reply message, and then processes the reply....The request thread awaiting the response implies that there is only one outstanding request or that the reply channel for this request is private for this thread.”²
Asynchronous transport protocols	Asynchronous transport protocols refer to protocols supporting activities wherein “one thread in the caller sends the request message and sets up a callback for the reply. A separate thread listens for reply messages. When a reply message arrives, the reply thread invokes the appropriate callback, which reestablishes the caller’s context and processes the reply. This approach enables multiple outstanding requests to share a single reply thread.”³
Mediation routing	Mediation routing is the specification of a complex “flow” of messages from component to component. For example, many middleware-based solutions depend on a message queue system. While some implementations permit routing logic to be provided by the messaging layer itself, others depend on client applications to provide routing information or allow for a mix of both paradigms. In such complex cases, mediation on the part of middleware simplifies development, integration, and validation. “Specifically, Mediators coordinate a group of objects so that they [do not] need to know how to coordinate with each other….Then, each consumer could focus on processing a particular kind of message, and the coordinator [Mediator] could make sure that the right message gets to the right consumer.”⁴
Process choreography and service orchestration	Process choreography and service orchestration are each forms of “service composition” where any number of endpoints and capabilities are being coordinated. The difference between choreography and service orchestration is: Choreography can be defined as an “asynchronous approach that enables processes to work autonomously, removing any issues caused by dependencies,”⁵ which is behavior resulting from a group of interacting individual entities with no central authority. Orchestration can be defined as a “synchronous approach that enables the execution of a query or process by allowing each microservice to implement tasks assigned by the orchestrator,”⁶ which is behavior resulting from a central conductor coordinating the behaviors of individual entities performing tasks independent of each other. In addition, “an orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.”⁷ Portions of business process choreographies can be built in Salesforce workflows or using Apex. We recommend that all complex orchestrations be implemented in the middleware layer because of Salesforce timeout values and governor limits, especially in solutions requiring true transaction handling.
Transactionality (encryption, signing, reliable delivery, transaction management)	Transactionality can be defined as the ability to support global transactions that encompass all necessary operations against each required resource. Transactionality implies the support of all four ACID properties, atomicity, consistency, isolation, durabilit, where atomicity guarantees all-or-nothing outcomes for the unit of work (transaction). While Salesforce is transactional within itself, it’s not able to participate in distributed transactions or transactions initiated outside of Salesforce. Therefore, it’s assumed that for solutions requiring complex, multi-system transactions, transactionality and associated roll-back/compensation mechanisms are implemented at the middleware layer. See http://en.wikipedia.org/wiki/Distributed_transaction.
Routing	Routing can be defined as specifying the complex flow of messages from component to component. In modern services-based solutions, such message flows can be based on a number of criteria, including header, content type, rule, and priority. With Salesforce integrations, it’s assumed that any such requirements are met by the middleware layer or the endpoint. Message routing can be coded in Apex, but we don’t recommend it due to maintenance and performance considerations.
Extract, transform, and load	Extract, transform, and load (ETL) refers to a process that involves: Extracting data from the source systems. This process typically involves data from several source systems, and both relational and non-relational structures. Transforming the data to fit operational needs, which can include data quality levels. The transform stage usually applies a series of rules or functions to the extracted data from the source to derive the data for loading into the end target(s). Loading the data into the target system. The target system can vary widely from database, operational data store, data mart, data warehouse, or other operational systems. While not strictly necessary, most mature ETL tools provide a change data capture capability. This capability is where the tool identifies records in the source system that have changed since the last extract, which reduces the amount of record processing. Salesforce now also supports Change Data Capture, which is the publishing of change events that represent changes to Salesforce records. With Change Data Capture, the client or external system receives near-real-time changes of Salesforce records. With this information, the client or external system can synchronize corresponding records in an external data store. See http://en.wikipedia.org/wiki/Extract,_transform,_load and Change Data Capture Developer Guide.
Long polling	Long polling, also called Comet programming, emulates an information push from a server to a client. Similar to a normal poll, the client connects and requests information from the server. However, instead of sending an empty response if information isn’t available, the server holds the request and waits until information is available (an event occurs). The server then sends a complete response to the client. The client then immediately re-requests information. The client continually maintains a connection to the server, so it’s always waiting to receive a response. If the server times out, the client connects again and starts over. The Salesforce Streaming API uses the Bayeux protocol and CometD for long polling. Bayeux is a protocol for transporting asynchronous messages, primarily over HTTP. CometD is a scalable HTTP-based event routing bus that uses an AJAX push technology pattern known as Comet. It implements the Bayeux protocol.

Term

Definition

Event handling

Event handling is the receipt of an identifiable occurrence at a designated receiver (“handler”). The key processes involved in event handling include:

Identifying where to forward an event
Executing that forwarding action
Receiving a forwarded event
Taking some kind of appropriate action in response, such as writing to a log, sending an error or recovery process, or sending an extra message

Keep in mind that the event handler can ultimately forward the event to an event consumer.

Common uses of this feature with middleware can be extended to include the popular “publish/subscribe” or “pub/sub” capability. In a publish/subscribe scenario, the middleware routes requests or messages to active data-event subscribers from active data-event publishers. These consumers with active listeners can then retrieve the events as they’re published.

In Salesforce integrations using middleware, the middleware layer assumes control of event handling. It collects all relevant events, synchronous or asynchronous, and manages distribution to all endpoints, including Salesforce.

Alternatively, this capability can be achieved with the Salesforce enterprise messaging platform by using the event bus with platform events.

See http://searchsoa.techtarget.com/definition/event-handler.

Protocol conversion

Protocol conversion “is typically a software application that converts the standard or proprietary protocol of one device to the protocol suitable for another device to achieve interoperability.

In the context of middleware, connectivity to a particular target system may be constrained by protocol. In such cases, the message format needs to be converted to or encapsulated within the format of the target system, where the payload can be extracted. This is also known as tunneling. ” ¹

Salesforce doesn’t support native protocol conversion, so it’s assumed that any such requirements are met by the middleware layer or the endpoint.

See https://www.techopedia.com/definition/30653/protocol-conversion.

Translation and transformation

Transformation is the ability to map one data format to another to ensure interoperability between the various systems being integrated. Typically, the process entails reformatting messages en route to match the requirements of the sender or recipient. In more complex cases, one application can send a message in its own native format, and two or more other applications can each receive a copy of the message in their own native format.

Middleware translation and transformation tools often include the ability to create service facades for legacy or other non-standard endpoints. These service facades allows those endpoints to appear to be service-addressable.

With Salesforce integrations, it’s assumed that any such requirements are met by the middleware layer or the endpoint. Transformation of data can be coded in Apex, but we don’t recommend it due to maintenance and performance considerations.

See http://en.wikipedia.org/wiki/Message-oriented_middleware.

Queuing and buffering

Queuing and buffering generally rely on asynchronous message passing, as opposed to a request-response architecture. In asynchronous systems, message queues provide temporary storage when the destination program is busy or connectivity is compromised. In addition, most asynchronous middleware systems provide persistent storage to back up the message queue.

The key benefit of an asynchronous message process is that if the receiver application fails for any reason, the senders can continue unaffected. The sent messages simply accumulate in the message queue for later processing when the receiver restarts.

Salesforce provides only explicit queuing capability in the form of workflow-based outbound messaging. To provide true message queueing for other integration scenarios, including orchestration, process choreography, and quality of service, a middleware solution is required.

See http://en.wikipedia.org/wiki/Message-oriented_middleware.

Synchronous transport protocols

Synchronous transport protocols refer to protocols that support activities wherein a “single thread in the caller sends the request message, blocks to wait for the reply message, and then processes the reply....The request thread awaiting the response implies that there is only one outstanding request or that the reply channel for this request is private for this thread.”²

Asynchronous transport protocols

Asynchronous transport protocols refer to protocols supporting activities wherein “one thread in the caller sends the request message and sets up a callback for the reply. A separate thread listens for reply messages. When a reply message arrives, the reply thread invokes the appropriate callback, which reestablishes the caller’s context and processes the reply. This approach enables multiple outstanding requests to share a single reply thread.”³

Mediation routing

Mediation routing is the specification of a complex “flow” of messages from component to component. For example, many middleware-based solutions depend on a message queue system. While some implementations permit routing logic to be provided by the messaging layer itself, others depend on client applications to provide routing information or allow for a mix of both paradigms. In such complex cases, mediation on the part of middleware simplifies development, integration, and validation.

“Specifically, Mediators coordinate a group of objects so that they [do not] need to know how to coordinate with each other….Then, each consumer could focus on processing a particular kind of message, and the coordinator [Mediator] could make sure that the right message gets to the right consumer.”⁴

Process choreography and service orchestration

Process choreography and service orchestration are each forms of “service composition” where any number of endpoints and capabilities are being coordinated.

The difference between choreography and service orchestration is:

Choreography can be defined as an “asynchronous approach that enables processes to work autonomously, removing any issues caused by dependencies,”⁵ which is behavior resulting from a group of interacting individual entities with no central authority.
Orchestration can be defined as a “synchronous approach that enables the execution of a query or process by allowing each microservice to implement tasks assigned by the orchestrator,”⁶ which is behavior resulting from a central conductor coordinating the behaviors of individual entities performing tasks independent of each other.

In addition, “an orchestration shows the complete behavior of each service whereas the choreography combines the interface behavior descriptions of each service.”⁷

Portions of business process choreographies can be built in Salesforce workflows or using Apex. We recommend that all complex orchestrations be implemented in the middleware layer because of Salesforce timeout values and governor limits, especially in solutions requiring true transaction handling.

Transactionality (encryption, signing, reliable delivery, transaction management)

Transactionality can be defined as the ability to support global transactions that encompass all necessary operations against each required resource. Transactionality implies the support of all four ACID properties, atomicity, consistency, isolation, durabilit, where atomicity guarantees all-or-nothing outcomes for the unit of work (transaction).

While Salesforce is transactional within itself, it’s not able to participate in distributed transactions or transactions initiated outside of Salesforce. Therefore, it’s assumed that for solutions requiring complex, multi-system transactions, transactionality and associated roll-back/compensation mechanisms are implemented at the middleware layer.

See http://en.wikipedia.org/wiki/Distributed_transaction.

Routing

Routing can be defined as specifying the complex flow of messages from component to component. In modern services-based solutions, such message flows can be based on a number of criteria, including header, content type, rule, and priority.

With Salesforce integrations, it’s assumed that any such requirements are met by the middleware layer or the endpoint. Message routing can be coded in Apex, but we don’t recommend it due to maintenance and performance considerations.

Extract, transform, and load

Extract, transform, and load (ETL) refers to a process that involves:

Extracting data from the source systems. This process typically involves data from several source systems, and both relational and non-relational structures.
Transforming the data to fit operational needs, which can include data quality levels. The transform stage usually applies a series of rules or functions to the extracted data from the source to derive the data for loading into the end target(s).
Loading the data into the target system. The target system can vary widely from database, operational data store, data mart, data warehouse, or other operational systems.

While not strictly necessary, most mature ETL tools provide a change data capture capability. This capability is where the tool identifies records in the source system that have changed since the last extract, which reduces the amount of record processing.

Salesforce now also supports Change Data Capture, which is the publishing of change events that represent changes to Salesforce records. With Change Data Capture, the client or external system receives near-real-time changes of Salesforce records. With this information, the client or external system can synchronize corresponding records in an external data store.

See http://en.wikipedia.org/wiki/Extract,_transform,_load and Change Data Capture Developer Guide.

Long polling

Long polling, also called Comet programming, emulates an information push from a server to a client. Similar to a normal poll, the client connects and requests information from the server. However, instead of sending an empty response if information isn’t available, the server holds the request and waits until information is available (an event occurs). The server then sends a complete response to the client. The client then immediately re-requests information. The client continually maintains a connection to the server, so it’s always waiting to receive a response. If the server times out, the client connects again and starts over.

The Salesforce Streaming API uses the Bayeux protocol and CometD for long polling.

Bayeux is a protocol for transporting asynchronous messages, primarily over HTTP.
CometD is a scalable HTTP-based event routing bus that uses an AJAX push technology pattern known as Comet. It implements the Bayeux protocol.