DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Rethinking Enterprise Integration: The Understated Role of Enterprise Service Bus (ESB)
  • Java: Mediator Design Pattern
  • Mediator Design Pattern in Java [Video]
  • Creating a Mule ESB Sample Hello World Application

Trending

  • Cookies Revisited: A Networking Solution for Third-Party Cookies
  • Artificial Intelligence, Real Consequences: Balancing Good vs Evil AI [Infographic]
  • Issue and Present Verifiable Credentials With Spring Boot and Android
  • Automatic Code Transformation With OpenRewrite
  1. DZone
  2. Software Design and Architecture
  3. Integration
  4. Understanding the Message Mediation on WSO2 ESB

Understanding the Message Mediation on WSO2 ESB

In this tutorial, we look at mediators and how they can be used to handle the messages that arrive in a WSO2 ESB sequence.

By 
Francisco Ribeiro user avatar
Francisco Ribeiro
·
Apr. 12, 18 · Tutorial
Likes (2)
Comment
Save
Tweet
Share
8.5K Views

Join the DZone community and get the full member experience.

Join For Free

One of the key pieces of the WSO2 ESB/EI development is the Mediation Sequence. Almost everything we develop is done inside sequences. Simply put, we can define a sequence as a way to group a set of mediators that will be used to handle the messages that arrive in the sequence. If we think of a Proxy Service or API, we usually have 3 sequences:

  • inSequence: Process the message received until it reaches the backend service.
  • outSequence: Process the response payload from the backend service until it reaches the client.
  • faultSequence: Used for Error Handling.

From that, we can understand that the sequences will contain the mediators that will be used to transform/process the message until its destination (the end of the sequence).

The mediators are well-defined components that perform a defined task. It is like the Unix Philosophy:

  • “Make each program do one thing well”: In our scenario, the program will be a mediator.
  • “Expect the output of every program to become the input to another”: The sequence will be the responsible for coordinating the programs and making the output of one mediator be the input of the next mediator.

In Linux, we can use the output of a program as an input for another using the “|” pipe. This way we can have combinations like below:

ls -ltr | grep *.txt

In the above example, we are listing all the items in the current directory and passing the output to the grep command where we are going to get only the lines that end with “.txt.”

In WSO2 ESB, the sequence could be compared to a big pipe, that makes it possible to use an output of a mediator as the input for the next mediator. Let us look at an example in the code below:

<sequence name="TransformMessage">
    <xslt key="My_xslt" />
    <send>
        <endpoint key="MyEndpoint" />
    </send>
</sequence>

In the example above, we have a sequence with two mediators:

  • xslt
  • send

The xslt mediator receives the incoming message and applies the transformation defined in the xslt file referenced by the mediator. The result of this mediator will be the transformed message, which means that at that point of the flow we have a new payload. And this new payload will be used as input for the next mediator in the sequence, in our example, the send mediator.

When we realize that, it becomes easier to understand what is going on when we see a sequence, and, hence, easier to develop on WSO2 ESB.

So, using the example above, let’s say that we use that sequence inside the inSequence of a proxy service, and this proxy receives the following request:

<bookRequest>
    <book>
        <id>123</id>
    </book>
    <user>
        <id>user1</id>
    </user>
    <start>2018-03-11<start>
    <end>2018-03-14<end>
</bookRequest>

This will be the payload used as the input of the first mediator in the sequence, in our case, the xslt mediator. After the xslt transformation, we will have a different payload, let’s say:

<bookRequest>
    <bookId>123</bookId>
    <userId>user1</userId>
    <start>2018-03-11<start>
    <end>2018-03-14<end>
</bookRequest>

As we can see, we have the request payload as input for the mediator (xslt) and the mediator produced a new payload. Then if we have another mediator in the flow, it will use the resulting payload from the previous mediator as input, instead of the original payload received in the request.

In this case, the payload that is going to be sent to the backend service, using send mediator, will be the last one generated by the xslt mediator.

That’s it for today.

I hope this post helps you understand the mediation flow on WSO2.

I hope you enjoyed!

See you in the next post.

Enterprise service bus Mediator (software)

Published at DZone with permission of Francisco Ribeiro, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Rethinking Enterprise Integration: The Understated Role of Enterprise Service Bus (ESB)
  • Java: Mediator Design Pattern
  • Mediator Design Pattern in Java [Video]
  • Creating a Mule ESB Sample Hello World Application

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: