Enterprise Integration Patterns (EIP)

1) Messaging Systems

a) Message Channel

A message channel is a logical channel that is used to connect the applications. One application writes messages to the channel and the other one (or others) reads that message from the channel. Message queue and message topic are examples of message channels.

b) Message Translator

A message translator transforms messages in one format to another. For example, one application sends a message in XML format, but the other accepts only JSON messages so one of the parties (or mediator) has to transform XML data to JSON. This is probably the most widely used integration pattern.

2) Messaging Channels

a) Publish-Subscribe Channel

This type of channel broadcasts an event or notification to all subscribed receivers. This is in contrast with a point-to-point channel. Each subscriber receives the message once and the next copy of this message is deleted from the channel. The most common implementation of this patter is a messaging topic.

b) Dead Letter Channel

The Dead Letter Channel describes the scenario, what to do if the messaging system determines that it cannot deliver a message to the specified recipient. This may be caused for example by connection problems or other exceptions like overflowed memory or disc space. Usually, before sending the message to the Dead Letter Channel, multiple attempts to redeliver messages are taken.

3) Message Construction

a) Correlation Identifier

Correlation Identifier gives the possibility to match request and reply message when the asynchronous messaging system is used. This is usually accomplished in the following way:
Producer: Generate a unique correlation identifier.
Producer: Send a message with the attached generated correlation identifier.
Consumer: Process messages and send a reply with the attached correlation identifier given in the request message.
Producer: Correlate request and reply message based on the
correlation identifier.

4) Message Routing

a) Content-Based Router

Content-Based Router examines message contents and routes messages based on data contained in the message.

5) Message Transformation

a) Content Enricher

Content Enricher as the name suggests enriching the message with missing information. Usually, the external data source like a database or web service is used.

6) Messaging Endpoints

a) Event-Driven Consumer

Event-Driver Consumer enables you to provide an action that is called automatically by the messaging channel or transport layer. It is an asynchronous type of pattern because the receiver does not have a running thread until a callback thread delivers a message.

b) Polling Consumer

Polling Consumer is used when we want the receiver to poll for a message, process it and next poll for another. What is very important is that this pattern is synchronous because it blocks the thread until a message is received. This is in contrast with an event-driven consumer. An example of using this pattern is file polling.

7) System Management

a) Wire Tap

Wire Tap copy a message and route it to a separate channel, while the original message is forwarded to the destination channel. Usually, Wire Tap is used to inspect messages or for analysis purposes.

Helm Commands

  1. export the kubectl config file
    export KUBECONFIG="/path/admin.conf"
  2. to retrieve the client and server version of helm
    helm version
  3. retrieve client and server version of the kubectl
    kubectl version
  4. list the helm repository in the local environment
    helm repo list
  5. update the helm repository
    helm repo update
  6. add the helm repository
    helm repo add <<chart-name>> <<repository-url>>
  7. update and download the dependent charts
    helm dep up <<chart-name>>
  8. Install the helm chart
    helm install <<chart-folder-name>> --namespace <<namespace>> --name <<release-name>>
  9. Retrieve or get values of the installed helm chart
    helm get <<release-name>> >> some-name.yaml
  10. list or verify the status of installed chart
    helm list
    helm status <<release-name>>
  11. list all pods in the namespace
    kubectl get po(d) -n <<namespace>>
  12. watch all pods in the namespace
    watch -d kubectl get po -n <<namespace>>
  13. delete all PVCs in the namespace
    kubectl delete pvc --all -n <<namespace>>
  14. describe the pod
    kubectl describe pod <<pod-name>> -n <<namespace>>
  15. describe the statefulset
    kubectl describe statefulset <<statefulset-name>> -n <<namespace>>
  16. describe the configmap kubectl describe configmap <<configmap>> -n <<namespace>>
  17. delete the helm release
    helm delete --purge <<release-name>>
  18. port forward to access the rest endpoints of the pod kubectl port-forward 7001:7001 <<pod-name>> -n <<namespace>>